[turinglambdaai]

Why

Rivet already has WatchConnectivity's typed request/router layer and a pinned RVD1→RVT1 companion client, but the iPhone-side bridge to the current authenticated desktop session is left to products. A product must never treat a reachable, paired Watch as desktop authorization.

Changes

• Add RivetWatchAuthenticatedRPCRelay to the WatchConnectivity library. No actions are registered by default.
• Register one typed RivetDeviceRequest alongside an exact product-selected desktop RPC and bounded RivetValue argument/result adapters. An incoming Watch message cannot choose arbitrary desktop RPC names.
• Resolve the product-owned current authenticated RVD1 session lease for every request; absent/revoked sessions return stable desktop_unavailable errors. Each lease carries a connection-unique UUID and is rechecked before returning a reply, discarding in-flight results after revocation or reconnect.
• Preserve the 64 KiB WatchConnectivity foreground envelope budget on the router, and rely on the desktop's existing independent per-device grants for final RPC authorization.
• Add deterministic JVM-free Swift tests for active session/revocation/reconnect races, route allowlisting, invalid/duplicate registrations, exact RPC argument dispatch and payload bounds.
• Update Apple SwiftPM target dependencies, documentation and changelog.

Scope and release gates

This is a reusable iPhone/watchOS framework handoff. The product must wire WCSession, the authenticated session provider and selected generated companion routes; it does not claim an iOS/iPadOS/watchOS signed application, background delivery, or physical-device acceptance. Require all six CI workflows, including the Swift runtime and watchOS/iOS cross-build, to pass before merge.