test(desktop): pin the RelayAgentInfo Tauri payload to snake_case

[rmichelena]

Summary

Add one regression test pinning that RelayAgentInfo crosses the Tauri boundary with
snake_case keys, and that the camelCase spellings never appear on the wire.

No behaviour change — this is a test-only PR closing a silent-failure hole.

Why

RelayAgentInfo is the payload of list_relay_agents and revalidate_relay_agents, and
the frontend maps it by hand. fromRawRelayAgent (desktop/src/shared/api/tauri.ts:655)
reads owner_pubkey, agent_type, channel_ids, respond_to and respond_to_allowlist
and rewrites them to camelCase for the RelayAgent type.

That contract rests entirely on the struct not carrying #[serde(rename_all = "camelCase")].
Adding it is the reflex when a Rust struct feeds a TypeScript client, and here it fails
silently in both directions:

• RawRelayAgent (tauri.ts:101) marks all five fields optional, so the mapper does not
  throw — it produces null / [] / null.
• Nothing in the repo asserts the wire shape, so no test goes red.

The runtime result is every relay agent arriving owner-less, typeless, channel-less and
with respondTo: null — which relayAgentIsSharedWithUser
(desktop/src/features/agents/lib/agentAutocompleteEligibility.ts:39) treats as deny.
The whole relay directory would quietly stop being mentionable, with a green build.

The blast radius grew recently: owner_pubkey and channel_ids were added to this struct
after the original mapper, so it is five hand-mapped fields now, not three.

Validation

just desktop-tauri-test runs this (.github/workflows/ci.yml:204 →
cd desktop/src-tauri && cargo test --workspace, path-filtered on desktop/src-tauri/**),
so the test actually executes in CI rather than only existing.

Acceptance criterion checked by breaking it, not just by watching it pass: adding
#[serde(rename_all = "camelCase")] to RelayAgentInfo makes the test fail on the first
assertion (owner_pubkey absent); removing it makes it pass again. A contract test that
does not go red when the contract breaks buys nothing.

• cd desktop/src-tauri && cargo test --workspace relay_agent_info_wire_keys — 1 passed
• cargo fmt clean

Notes

The test lives next to the existing serde-contract tests in the same file
(respond_to_serde_is_kebab_case, and the needs_restart / restart_diff snake_case
assertion at the end), so it follows the file's established shape rather than introducing
a new one.

Split out of #5483, which I closed as superseded by #6086 / #6182 / #6224 — those PRs
implemented the directory work it proposed, but nothing carried this contract test across.

[rmichelena]

Rebased onto main (4cd82f513) — 499963fe6. The test applies unchanged: RelayAgentInfo still carries the same ten fields in the same order, and still has no rename_all, so the contract this pins is the one main relies on today.

Re-verified against current main rather than assumed:

Check	Result
cargo test --manifest-path desktop/src-tauri/Cargo.toml relay_agent_info_wire_keys	1 passed, 0 failed
Same test with #[serde(rename_all = "camelCase")] injected on RelayAgentInfo	FAILED (exit 101)

The second row is the point of the PR: the acceptance criterion was proven by breaking it. Nothing else in the repo fails when that attribute is added, yet fromRawRelayAgent in desktop/src/shared/api/tauri.ts reads owner_pubkey, agent_type, channel_ids, respond_to and respond_to_allowlist by hand — all five would silently become undefined, and RawRelayAgent marks them optional, so the mapper would emit null/[] and every relay agent would turn owner-less, typeless and un-mentionable at runtime with no compiler or test objecting.

No CI has ever run on this branch: the workflow runs sit at action_required awaiting first-time-contributor approval, and the August ones have begun expiring at the 30-day mark, which GitHub concludes as failure with zero jobs executed. That red ❌ is the expiry, not the code. An Approve and run workflows would give this its first real signal.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 4cd82f513214aad11c2b742ce7cc7c681e8e32a0...499963fe683a8573a7620dd3245ecd6a495795f5.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 499963fe683a8573a7620dd3245ecd6a495795f5 to authorize a new review.
Any previous review applies only to its recorded range.