fix: arm safe mode for never-connected consumers and harden snapshot and photon fee edges

[giunatale]

Four consumer-side hardening items.

Never-connected consumers now enter safe mode

LastVSCRecvTime was only ever set on packet receipt, and the getter fell back
to the current block time when unset, so a consumer that never received a
validator-set update was never considered stale and never entered safe mode.
The clock is now armed at the first block after genesis: the genesis block
itself carries the genesis file's genesis_time, which may predate launch, so
arming any earlier would burn safe-mode budget before the chain produced a
block. SafeModeThreshold staleness therefore accrues from launch. An explicit
timestamp from a restart genesis still wins, a restart genesis without the
field arms the same way, and every accepted update re-arms the clock. (A
pre-VAAS standalone chain deliberately stays unarmed until its first update: a
live standalone economy must not enter restricted mode mid-changeover.) The
liveness documentation asserted the old behavior and was corrected.

A packet can no longer empty the validator set

A well-formed packet whose application would leave the consumer with an empty
validator set halts the chain at EndBlock. OnRecvVSCPacketV2 now rejects such
packets with an error acknowledgement before any state write, for snapshots
(the packet's positive-power updates are the entire resulting set) and for
diffs (the current set overlaid with pending changes plus the packet,
reproducing exactly what EndBlock would apply). Rejection happens inside the
IBC cache context, so no state leaks; out-of-order stale packets still
deduplicate to a success acknowledgement first, preserving replay semantics.
Heartbeat diffs over a live set are unaffected.

Photon fee decorator: bypass closed, bootstrap and exemptions made explicit

The expected fee denom stays derived from the pinned provider client
(ibc/SHA256("transfer/<clientID>/uphoton")): under client authentication the
pin moves at most once at bootstrap, and IBC vouchers can only ever arrive over
the adopted, routable client, so the derived denom tracks exactly the denom
real vouchers carry, while a static genesis-time parameter could never name the
adopted client id. Vouchers bridged over any other path are deliberately not
accepted: they cannot be verified locally, and accepting them would take a
governance-maintained denom whitelist. The decorator godoc documents both.

Behavior splits on pin routability:

• Bootstrap (no pin, or the unroutable genesis pin): full no-op. No voucher can
  exist yet, so there is nothing to police, and rejecting the fee-less relayer
  traffic of that phase would block the first validator-set update forever. The
  message-filter decorator remains the traffic restriction for that phase.
• Enforcing (routable pin): every fee coin must be the derived voucher denom
  AND the fee must be non-empty, closing the empty-fee bypass. Gas simulation
  is exempt from the non-empty check only; a wrong denom still rejects in
  simulation.

Transactions made up exclusively of infrastructure messages stay exempt while
enforcing: /ibc.core.* and /cosmos.gov.*, with the user-originating
MsgSendPacket carved out, and one non-exempt message makes the whole tx
enforced. The vouchers the policy demands can only arrive in relayer-submitted
packet deliveries, so pricing those in photon would deadlock the chain the
moment the policy activates. What exempt transactions pay stays node-local
min-gas-prices policy: a tokenless core shard launches with zero prices and
genesis-declared relayer and owner accounts, and raises prices once photon
circulates.

The decorator is wired, not shipped inert

PhotonFeeDecorator is now always part of the reference consumer app's ante
chain, inserted immediately before fee deduction, and the on/off decision is a
consumer module parameter (photon_fees_enabled, default false) rather than
node-local configuration.

That distinction is the point. The decorator rejects transactions in
FinalizeBlock, not only in CheckTx, so it is consensus-relevant: driving it
from app.toml would let two validators disagree on whether a transaction is
valid, diverging the app hash and halting the chain, and the trigger would be
as mundane as a validator joining after launch with the shipped default. As a
parameter it comes from state, so every node agrees, and it round-trips through
genesis. The provider-authored consumer genesis always writes it off; enabling
takes a hand-authored genesis or a later MsgUpdateParams from the params
authority, where the embedding app wires one. The reference consumer app wires
no governance, so there the genesis choice is final.

New app-level tests build the real consumer app once per parameter setting and
run fully signed transactions through the real ante chain against real keepers:
enabled + voucher denom accepted and deducted; enabled + wrong denom rejected
(from an unfunded account, proving the rejection is policy, not funds); enabled

• empty fee rejected; bootstrap no-op; disabled permissive. The infrastructure
  exemption set is pinned by dedicated ante tests.

The main e2e suite runs its consumer with photon_fees_enabled set in the
consumer genesis, the way a real core shard would enable it, so the whole suite
exercises the policy, and testPhotonFeeEnforcement proves the loop end to
end: a native-fee tx is rejected by the ante, an ICS-20 v2 transfer bridges
uphoton in while enforcement is on, and a bank send paying voucher fees
commits.

Testing

Unit + app-module suites green (including the app module's first ante tests);
golangci-lint clean; both Docker e2e suites pass: the main suite 17/17 with
photon fees enforced suite-wide, the liveness suite 5/5 including its safe-mode
scenarios under the BeginBlock-armed clock.

[giunatale]

Branched from giunatale/feat/client-authentication (#65) (hard dependency: the photon fee semantics build on the pinned provider client). Opened against that branch; will retarget to main once it lands.

Note for reviewers: two statements in this PR's docs/consumer-liveness.md edits describe the end state of the coordinated PR set, not this branch in isolation — the CLI example uses the vaasprovider subcommand root that the cleanup PR introduces, and the snapshot-trigger list includes the empty-stored-valset condition that the genesis round-trip PR adds. Both are deliberate, so the merged documentation is correct and conflict-free; they read one step ahead only until those two PRs land.

[julienrbrt]

lgtm!

[tbruyelle]

A few comments, with the most important of which is: how do we transfer photons if we already need bridged photons to pays the fees ?