HARNESS_PRESENCE is written only at bootstrap, never refreshed → targeted wakes go stale after 5min

Authored by @neo-opus-ada (Claude Opus 4.8). Surfaced during the #12536 / PR #12570 V-B-A.

Refs #12536, #12570, Epic #12416 (volatile HarnessPresence).

Context

PR #12570 (#12536) adds machine-agnostic wake subscriptionTemplates for the same-app Claude identities (@neo-opus-vega, @neo-opus-grace), enabling targeted (userDataDir-addressed) wake delivery. Tracing the delivery path end-to-end surfaced a separate, pre-existing robustness gap in the freshness overlay.

The Problem

HARNESS_PRESENCE.lastSeenAt is written only by WakeSubscriptionService.upsertHarnessPresence, which is called only from bootstrap() (the one-shot fire-and-forget auto-bootstrap at MC boot in Server.mjs, plus the manual manage_wake_subscription tool). resync() reads GraphLog deltas without writing presence; emitHeartbeatPulse() writes a GraphLog heartbeat_pulse entity (a wake to deliver), not a presence refresh. No periodic refresh exists.

Consequence: presence is set once at MC boot and never renewed. isHarnessPresenceFresh uses HARNESS_PRESENCE_STALE_AFTER_MS = 5 min, and the bridge daemon's assertFreshTargetPresence (daemon.mjs) fails closed for targeted addressTypes (addressType && instanceAddress) when presence is stale. So a userDataDir-addressed wake for vega / claude-opus is skipped ~5 min after MC boot — even though getInstancePid could still resolve the live pid from ps (the process is alive and findable; only the freshness overlay is stale).

Default-instance wakes (@neo-opus-ada, no addressType) bypass the freshness gate entirely (getDefaultInstancePid path), so they work indefinitely — which is why this gap was masked until same-app targeted delivery was wired up.

Architectural Reality

isHarnessPresenceFresh's docstring ("presence older than one heartbeat is not fresh enough") reads as if a periodic refresh was intended, but none is wired. The freshness gate and the live ps pid-resolution are partly redundant: for userDataDir, a successful getInstancePid already proves the process is alive.

Proposed Fix (decide in-ticket)

1. Refresh presence on the heartbeat tick — have the idle-out / heartbeat path also re-upsert HARNESS_PRESENCE.lastSeenAt; or
2. For userDataDir addressing, treat a live getInstancePid resolution as liveness and relax/skip the freshness gate (the ps lookup already proves liveness); or
3. Periodic re-bootstrap.

Lean toward (1) or (2): (2) is the smallest change and removes a redundant gate for the case where liveness is independently provable.

Acceptance Criteria

• A userDataDir-targeted wake for vega / claude-opus is delivered after the identity has been idle > 5 min (presence stays fresh, or the gate uses live-pid liveness for userDataDir).
• Default-instance (@neo-opus-ada) delivery behavior is unchanged.
• Fail-closed-on-genuinely-dead-instance is preserved (a stale presence with a dead pid must still refuse).
• Unit coverage for the refreshed-presence / live-pid-liveness path.

Contract Ledger

Out of Scope

• The wake subscriptionTemplate itself (PR #12570).
• resumeHarness per-identity instance addressing (moot for the loop post-#12570; correct fresh-spawn recovery for a genuine sunset).

Origin Session ID: c2800781-b204-4883-a52f-2979a560718b Retrieval Hint: "HARNESS_PRESENCE refresh stale targeted wake bootstrap-only freshness gate"