tenant.openagents/omega

Answer the provider connection handoff the phone can already ask for (omega#91)

Answer the provider connection handoff the phone can already ask for (omega#91) A paired device could hold `request_provider_handoff` and send `action.omega.provider_handoff`, and nothing answered. The contract was complete, the `fullauto.v1` wire carried handoffs end to end, and the vector was empty in production forever, because no part of the daemon produced a record. The phone rendered a capability the host had nothing to say about. This is the thing that has something to say: a host-owned ledger with one lifecycle — requested, bound to an account, terminal — committed with the rest of the durable Issue 31 host state. Every field on a record is a measurement rather than a claim. `requestedAtMs` is one reading of `now` taken when the host admitted the command, stamped once. The account binding is chosen from the host's own roster. The terminal outcome and the reason for a non-successful end are decided from what the host observed. The device's entire input surface is a provider token, so there is no wire field through which it could state any of them. Binding and completing are separate roster observations, one per host pump pass, so a phone sees the handoff appear, bind, and settle rather than jump. The roster is read through the same `parse_provider_accounts` the desktop provider roster renders, which is what makes `handoff.accountRef` -> `account.laneRef` the account-to-lane relation omega#42 asked for rather than a second opinion about the host's capacity. A handoff in flight when the process ends is settled `failed` / `reason.omega.handoff_host_restarted` at load. The isolated provider home and the login it drove died with that process, so the honest terminal answer is that it was interrupted; that direction can only under-claim, and it is what stops a restart leaving the phone with a request that neither resolves nor fails. Nothing is backfilled. A row persisted before `requestedAtMs` existed decodes, is reported unavailable, and is refused rather than stamped at load time, which would give one field two provenances nothing on the wire distinguishes. A request the host never admitted leaves no record at all. That is what makes a failed handoff distinguishable from one that never started: one is a row carrying a host-owned reason and outcome, the other is an empty list. The record carries the fact of a connection and never the connection secret. Nothing here reads, writes, or names a provider credential, an isolated provider home, or a path, and no provider login is run. Every projected row is routed back through `workroom_receipts::decode_issue31_provider_handoff`, the exact function the whole-document decoder uses, so the host cannot write a handoff the phone would refuse. Proven against the deployed `relay.openagents.com`: a device publishes a real signed command intent, the shipped pump reads it back off the relay, and the handoff appears, binds and completes — and, in a second run, a scope-denied ask leaves no record while an admitted one ends `refused` with a host-owned reason. `openagents.omega.issue31.fullauto.v1.host-produced-handoffs.json` is the fourteenth byte-shared fixture and is not written by hand: it is exactly what the ledger emits across all six lifecycle states. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>