feat: bind consumer and provider IBC clients by explicit owner declaration

[giunatale]

Review follow-up (713ed6b, on top of the reviewed commit): client discovery and
first-packet adoption are replaced by explicit, owner-signed, once-only
declarations on both chains.

Why

Inferring the binding was broken both ways. A creation-time consensus state is
stored unverified, so a forged client carrying the provider's own (public)
consumer-valset hash wins any content comparison. And an honest consumer that
is not bound within two epochs falls out of the compared hash window, because
the provider rotates its stored valset every epoch, and is eventually deleted
by the liveness sweep.

How it works now

• Provider: the owner sets an optional client_id on MsgUpdateConsumer,
  exactly once. The client must exist, be an Active tendermint client of the
  consumer's chain id, have a registered IBC v2 counterparty, and have a
  trusting period above the downtime challenge horizon (evidence max age plus
  challenge window), so accepted accusations stay disprovable. Registration
  rejects an unbonding period at or below that horizon. Until declared, VSC
  packets stay queued.
• Consumer: genesis creates no client and only seeds the provider chain id. A
  new chain rejects every VSC packet until the owner (a new owner_address
  consumer param seeded by the provider; governance always may) pins the
  relayer-created client with the new MsgSetProviderClient, validated the
  same way. Owner matching compares address bytes across bech32 prefixes. The
  pre-pin message filter admits /ibc.*, the pin message, and /cosmos.gov.*.
• Both bindings are permanent. Client ids are identity (downtime state, photon
  fee denom), so a dead client is recovered in place via governance
  MsgRecoverClient. Known residual: a malicious owner can declare a client of
  a chain they control; forged downtime evidence from it is answered by the
  challenge mechanism.
• A consumer restarting before being pinned now round-trips its genesis instead
  of exporting a default one.

Upstream ibc-go issue found by the restart e2e

clientv2's genesis Validate rejects client_id == counterparty.client_id,
but those ids are from different chains' namespaces and collide naturally (two
fresh chains both name their first client 07-tendermint-0). ibc-go's own
MsgRegisterCounterparty accepts the pairing, so exported state cannot be
re-imported: any restart from export panics at InitChain. Present in v10.2
through v10.7; needs an upstream report. ea437e0 wires app/ibcshim into both
apps as a workaround: it mirrors ibc core InitGenesis and skips only that
check, with a sentinel test that tells us when upstream fixes it.

Operating

Register the consumer from an account whose address bytes exist on both chains
(e2e/localnet derive an owner key at HD index 1 of the shared mnemonic), then
after the relayer creates the clients: tx provider update-consumer with
client_id, and tx vaasconsumer set-provider-client. The e2e harness and
make localnet-declare-clients do both.

Testing

Every declaration and pin rejection is unit-tested and mutation-checked; the
registration floor, owner seeding, unpinned restart round-trip, and pre-pin
filter each have dedicated tests. The liveness e2e clock was rescaled (400s
unbonding, 60s/120s downtime windows) to stay coherent with the new trusting
check. Liveness suite 5/5; main suite green with the ibcshim workaround.

[giunatale]

Branched from giunatale/feat/consensus-key-rotation (#64) (hard dependency: needs atomone-sdk v0.500.2 and the rotation hooks). Opened against that branch; will retarget to main once it lands.

[tbruyelle]

The PR introduces a clear improvement of the client id healing process, but there's still possibility to front-run the client id pin, with the consequences of having to restart the consumer bootstrap.

Added 2 comments, one for consumer and one for provider client id healing, both avocate for an extra manual step instead of the self-healing.