fix(sim): name the api-interface on each lava-sim policy

[VicSheCodes]

ON HOLD — do not merge until MAG-3046 is done.

This change is correct in itself, but it only matters for cross-validation policies that
currently sit on the shared lava-sim-rest, lava-sim-tm and lava-sim-grpc routers.

Those policies are being removed. An operator policy with enabled: true makes
cross-validation mandatory for that method, for every caller, on a router that 30 other
tests already use. It broke 8 tests on lava-sim-rest immediately: a cross-validated reply
carries the lava-cross-validation-* headers instead of Lava-Provider-Address, and
those tests assert the latter as proof the router is in the request path.

MAG-3046 replaces them with dedicated cross-validation routers, so the shared ones go back to
behaving as they did.

When MAG-3046 lands, this PR is either rebased onto the new routers or closed. Do not
merge it against the shared routers.

---

#Closes MAG-2791

Why

A cross-validation policy is found by three things together: chain, interface and method. The chart
inherits chain-id from the router, but not the interface:

api-interface: {{ $policy.api_interface | default "jsonrpc" }}

So a policy that does not name an interface is filed under jsonrpc. The lava-sim-rest,
lava-sim-tm and lava-sim-grpc routers serve rest, tendermintrpc and grpc, so their
policies sat under an interface no request on them ever uses. Nothing matched, the routers started
clean, and every request was served by a single provider.

Verified on the deployed cluster

Before: both REST and Tendermint replies carried lava-provider-address, which the router only
sends when cross-validation did not run.

After: they carry the cross-validation headers, and the agreeing providers span both groups.

lava-cross-validation-status: success
lava-cross-validation-all-providers: ...primaryprovider1,...primaryprovider2,...primaryprovider3
lava-cross-validation-agreeing-providers: ...primaryprovider2,...primaryprovider3

primaryprovider2 is in voting-group-1 and primaryprovider3 in voting-group-2, which is the
acceptance criterion for this ticket.

What changed

One line per policy: api_interface: "rest" / "tendermintrpc" / "grpc".

The local k3d chart uses $router.interface instead of the default, so the same values behave
differently there than in production. That difference is what hid this.

Not covered

gRPC could not be probed. That router refuses plain grpc:// upstreams without allow-insecure,
which appears nowhere in the values and predates this change.