fees: cross-zone dispatch fee model (account-less invocations have no payer)

[erhant]

Cross-zone dispatches carried by account-less built-in invocations have no fee model. The concrete blocker (moudy, #762 cross_zone_ping.rs:37): ping_sender's Send is an unsigned, account-less invocation — there is no payer account to charge, and the fee guest's fixed two-account arity leaves no room to add one. ping_sender is a registered built-in (not a test fixture), so this is a real gap, not test debt.

The integration test ping_crosses_from_zone_a_to_zone_b is currently #[ignore]d for this reason.

Caution

Under the interim fee policy, system-injected / cross-zone dispatch transactions are fee-exempt (like bridge deposits and other injections), so nothing charges for cross-zone traffic today. That's fine as a placeholder but leaves cross-zone dispatch unpriced.

Open design questions

• Who pays for a cross-zone dispatch — the emitting user, the sequencer, a zone-level account?
• For account-less invocations (ping_sender::Send), where does the payer come from, given the guest's fixed account arity? Does the emitter carry a fee declaration, or is cross-zone traffic priced at a different layer (e.g. the Bedrock inscription)?
• How does this interact with the producer-reward / stake-ownership routing being settled separately?

Needs a spec decision before the ignored cross-zone tests can assert real fee behavior.

[erhant]

Interim mitigation (not a fix): as of commit 6417d75db within #801, empty-witness ping_sender.Send is recognized as a system injection in is_system_injection and treated fee-exempt, purely to keep the cross-zone example tests enabled (cross_zone_ping, cross_zone_verified, cross_zone_watcher_restart).

This only exempts the one known ping_sender.Send shape — it does not solve this issue. Outbound cross-zone sends are account-less (no payer) and can be initiated by arbitrary programs, which a shape-based classifier can't enumerate.

[erhant]

Spoke with @moudyellaz today, we decided to keep cross-zone stuff fee-exempt for now (w.r.t #801) until we come up with a better fix later. So, this issue may persist for a bit.