fix(billing): answer an in-flight retry at once, and tell Chat what provenance withheld - #9094

Summary

• Billing in-flight retry.
  • Before: the cost callback waited up to lock_timeout on the per-request ledger lock. While an earlier attempt of the same request was still committing (a commit can wait on a synchronous standby while holding that lock), a retry held a pooled connection for 3s and then failed with a 500 plus an ERROR log.
  • Now: the lock is try-acquired. A held lock answers 503 with code: BILLING_REQUEST_IN_FLIGHT and Retry-After: 5 immediately, logged at INFO.
  • The monotonic max-cumulative top-up is unchanged, so a resend can neither double-charge nor lose a charge.
  • lock_timeout still bounds the row locks taken under the ledger lock.
• Provenance refusal logging.
  • Refusals are policy, not faults: they log at WARN instead of ERROR.
  • Each gate admission logs one line per (surface, cause), not one per item.
  • Each line keeps top-level surface, cause and refusedCount, plus the refused ids as each line names them today (up to 200, flagged resourceIdsTruncated beyond that), so every id stays paired with its cause. A single refusal keeps its resourceId field.
  • The table-row unknown-envelope line is now a WARN. Writer defects stay at ERROR.
• Withheld items in Chat results.
  • Gate verdicts now carry the refusal reason.
  • A new countWithheldContent wraps each Chat CLI request. When items were withheld, the CLI's stderr says, per kind and reason, what the model can do next, and names no item:
    • unknown provenance: reading it again will not return it;
    • recorded secrets: read it as text for a redacted copy;
    • provenance not verified: it may be readable later.
  • v2 API bodies and headers are unchanged. Callers outside Chat never classify content, so they see no note.
• In-flight refusal logging. An in-flight refusal no longer triggers the usage ledger's "did not complete promptly" WARN; the route logs it once at INFO. The span keeps the existing internal_error outcome, because the closed outcome set is generated from the legacy contracts.
• Comment fixes. The worker's callback timeout is 15s, not 5s. No transaction setting bounds a commit that is waiting on a standby.
• Contract. BillingInFlightCode is synced from the worker contracts.

Companion: simstudioai/mothership#705

Release order: either order is safe.

• A worker without the companion change treats this 503 as retryable: it retries in-loop and then hands off to replay.
• A worker with it, running against a Sim without this PR, simply never sees the code.

Type of Change

• Bug fix

Testing

Each of these fails without this PR and passes with it:

• usage-log.integration.ts:
  • New: a retry behind a holder of the same request is refused at once with the in-flight error. Before this PR it waited 3s and failed with a 55P03.
  • The recovery and concurrent-convergence tests now resend in-flight refusals the way replay does, and still converge to the exact totals.
• route.test.ts: the in-flight error maps to the 503 with its code and Retry-After. Before this PR it returned a 500.
• registry-gate.test.ts and session-gate.test.ts: verdicts carry the refusal reason, and 50 refusals produce one batched report.
• durable-secret-provenance-telemetry.test.ts: 163 refusals produce one line per cause, each keeping every id. A 250-item group is capped at 200 ids and flagged as truncated.
• content-delivery.test.ts: countWithheldContent counts refusals by kind and reason across nested requests, and counts nothing for non-Chat callers.
• telemetry.test.ts: the note wording is checked for each refusal reason.
• usage-log.test.ts: an in-flight refusal emits no slow-transaction WARN.
• file-provenance.test.ts: the CLI result carries the reason-specific note.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)