Require a confirming heartbeat before making dynamic runners available #61

Runtime capability contract

The Go App Reconciler consumes this confirmation behavior together with #62 mutation fencing. Advertise capabilities.registration_confirmation=true in successful heartbeat responses only when initial registrations remain unavailable across every admission/discovery path until a successful issued-credential heartbeat. Independently advertise ordered_mutations and app_cancellation only when those contracts are implemented; do not infer compatibility from a version label.

Return runner/app IDs, issued credential, TTL and per-app status/session_ids before confirmation. The consumer must persist identity synchronously before the confirming heartbeat; persistence failure terminates its loop. Initial or recovered snapshots are non-ready, and automatic bootstrap retry from an old ready snapshot is disabled. Lost initial responses must not create duplicate available capacity; an unconfirmed fixed identity may remain pending until TTL expiry, or the consumer can use a fresh identity with IDs omitted. Node restart/expiry loses Node session state and cannot promise session continuity.

Local Runtime rendering/state/Flux/probe implementation proceeds without this ticket. Production admission remains dependency_pending until this capability and ordering are verified with compatible images. Native SDK hook work is golang-runner #7; credential getter/restore #5 remains closed.

Related: livepeer/naap-ops#114

Delay availability of a newly registered dynamic runner until Node receives one additional successful heartbeat authenticated with that runner's issued heartbeat credential.

The initial bootstrap-authenticated registration currently makes ready apps available immediately. If its response is lost, the runner never receives its assigned IDs or heartbeat credential, and cannot resume that registration. Retrying as a fresh identity can then leave two advertised registrations for the same app endpoint.

Proposed behavior

• Accept the initial registration and return Node-assigned runner/app IDs, heartbeat credential and normal heartbeat/O2R information, but keep the runner pending confirmation.
• Exclude pending runners' apps from discovery and reject new reservations/application admissions through all routes, including direct single-shot and proxy routes.
• Confirm the runner only after a subsequent valid heartbeat authenticated with its issued runner-scoped credential. Apply the submitted app snapshot atomically; only apps whose current status is ready become available.
• Expire unconfirmed registrations using the existing heartbeat TTL.

The App Reconciler persists the first successful registration response before sending the confirming heartbeat. If that initial response is lost, it can register fresh with runner/app IDs omitted so Node assigns new IDs. The abandoned pending registration expires without having served sessions or advertised duplicate capacity. Fresh registration is the recovery path for a lost initial response, not ordinary restarts with saved registration state.

Acceptance

• Initial registration returns credentials and assigned IDs, but its apps remain undiscoverable and cannot admit work through any route.
• The next successful scoped heartbeat makes ready apps available; bootstrap authentication, invalid credentials and rejected snapshots do not confirm a runner.
• Simulate a lost initial response, then register fresh with Node-assigned IDs: only the confirmed registration advertises capacity or serves requests, and the abandoned registration expires.
• Confirmation respects readiness and an empty apps snapshot.
• Established dynamic runners, sibling app sessions and static-runner availability retain their existing behavior.