[defer] feat(calls): record rendered-content presence and usage provenance per request

[maxmad64bis]

⚠️ base-red inherited: #14547

Call logs could not tell an empty success apart from a missing usage counter, so debugging silent responses meant guessing which side failed. Each successful request now records whether client-visible content was rendered (has_content) and where the usage numbers came from (usage_provenance: reported, estimated, or absent), with both columns left null whenever nothing was measured. Existing columns keep their exact semantics and the journal screen is unchanged (follow-up PR).

Summary

Call logs could not tell an empty success apart from a missing usage counter: each successful request now records whether client-visible content was rendered and where the usage numbers came from, with both columns left null whenever nothing was measured.

Related Issues

• No linked issue — self-contained observability follow-up with no tracked issue; additive nullable columns with a fresh migration.

Validation

• Change type: DB
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• tests/unit/call-content-provenance.test.ts (new, 10 cases): empty vs content-bearing success, silent provider, threaded and rebuilt estimates, reasoning-only, tool-calls-only, non-text route, failure, fresh-database migration; failing before the fix (RED), passing after (10/10).
• Neighbor call-log suites rerun green, unchanged (143/143).

Coverage Notes

• The new helper (src/lib/usage/callContentProvenance.ts) and the sink lines in src/lib/usage/callLogs.ts are covered branch by branch by the new suite, including the null-when-unmeasured paths (non-success, logging disabled, non-text output).
• No coverage decrease expected: the change is purely additive and all neighbor suites stay green.

Reviewer Notes

• Strictly additive: two nullable columns (migration 190, plus back-fill for lineages that skipped the file); existing readers and queries are untouched.
• Docs-counts sync: README/AGENTS/llm.txt migration count 183→187 with this migration (STRICT gate green locally; base said 183 for a real 186).
• Success is strictly 2xx (200–299): an empty success reads as a visible 0, never confused with unmeasured NULL; a missing counter reads as absent, never as an error.

Maintainer rework (merge-batch 2026-09-24)

• Merged release/v3.8.51 into the branch (real merge, author commit preserved) to clear the conflicts with the tip.
• Dropped the migration-count edits to AGENTS.md, README.md, llm.txt and the 66 docs/i18n/*/llm.txt mirrors: the count was already stale against the tip, those are agent-instruction surfaces, and they were the source of the conflicts. The count is synced once for the whole batch in a follow-up.
• Kept as-is: code, migration 190_call_logs_content_provenance.sql (the tip ends at 189), the four requestLogger.detail keys in all locales, and the tests. Series order for the batch: 190 ([defer] feat(calls): record rendered-content presence and usage provenance per request #14795) → 191 ([defer] feat(call-logs): record per-request resilience actions in call logs #14810) → 192 (feat(sse): record per-request added wait with cause in call logs #14756).

[diegosouzapw]

Migration number coordination: several open PRs claim the same slot, and the release tip is already at 189 (187_proxy_logs_attempts, 188_call_logs_reasoning_encrypted, 189_quota_schedules). This PR's migration (190_call_logs_content_provenance.sql) gets 195. Please rename the file and update every reference to the number. Slots go by PR age, and merges happen in ascending order so the numbering gate stays contiguous.