fix(playback): bound stale-pin recovery re-list with the shared damper

[randrini]

Problem

Closes #237
Follow-up from PR #234 (merged). The stale-pin recovery re-list ran outside the virtualRecoveryRelists damper bounding the sibling fallback.

Approach

Route the recovery re-list through the shared damper with identical acquire/accounting semantics: exhausted budget yields deterministically to alternates (terminal preserved); answered listings clear the key; empty/failed answers accumulate. 500ms sub-budget, single-retry bound, transient-only semantics, session-bound refusal, and fingerprint matching unchanged.

Validation

• New damper tests: exhausted budget yields with zero resolve/pin (no sleeps); answered listing clears the key
• Full handlers suite green incl. -race; gofmt/vet clean
• Full CI green on the final head required

Risks

Under damper exhaustion the recovery skips its re-list where it previously attempted one — same deterministic yield as the sibling fallback. No API, migration, or config impact.

Checklist

• I read and can explain the complete diff.
• This pull request addresses one concern.

AI Disclosure

• Harness: OpenCode
• Tool(s): OpenCode (oracle, fixer subagents)
• Model(s): opencode-go/muse-spark-1.3-contributor
• Involvement: AI-assisted

[randrini]

Ready for review: damper-bound recovery re-list with shared accounting, full suites + -race green. Awaiting dev verdict + CI confirmation — no merge until approved.

[drondeseries]

Review — APPROVE

Small, safe, one-concern fix. Verified against head 01641ed8:

• Shared damper key matches the sibling paths: virtualRecoveryRelistKey(neutralKey, ownerID) with neutralKey = virtualPlaybackNeutralKey(file.FilePath) — same identity as resolveVirtualPlaybackSource (:2008) and the stale fallback (:4972). Same budget, same window.
• Acquire-before-list / clear-on-answer / accumulate-on-empty matches fallback (playback_virtual.go:5006) and resolver (:2194). Clear placement before the pin-absent/fingerprint/resolve gates is correct — a listing that answered is no longer defeating fail-fast.
• Exhausted budget returns {}, false with WarnContext, terminal preserved, no sticky/durable side effects (pinned by the new test).

Tests: TestStalePinRecoveryReListHonorsSharedDamper (exhausted → zero listings/resolves/sticky writes, durable pin unchanged) and TestStalePinRecoveryReListClearsBudgetOnAnswer cover the accounting both directions. All 8 CI checks green.

Non-blocking nits:

• Generation is allocated before the damper check here but after it in resolveVirtualPlaybackSource (:2023). A denied recovery burns one generation number — harmless, just inconsistent.

Safe to merge as-is.