[Buyer Gap] Add evidence-honest knowledge-cutoff scope to Global Ask

[seonghobae]

Buyer problem

The Buyer-surface stack now preserves analysis-run knowledge_cutoff, per-post live_after_cutoff, and cutoff body evidence when a buyer opens a recorded run. Global Ask still assembles only the current live source_post state and exposes no first-class as-of scope.

A buyer asking “What did we know by 2026-01-15?” can therefore receive a current answer without a machine-verifiable statement that the cited body and semantic facts existed by that cutoff. Adding a date only to the prompt would be misleading; the retrieval boundary itself must be cutoff-aware.

Product contract

Add an optional, explicit Global Ask scope:

{
  "question": "What did we know about Phoenix by the cutoff?",
  "knowledge_cutoff": "2026-01-15T12:00:00Z"
}

Retrieval

• Select only source records whose evidence was available at or before the cutoff.
• Resolve each selected post to the latest eligible source_post_revision/snapshot at or before the cutoff.
• Resolve persisted project, role/responsibility/affiliation, Keyman, graph, and content-artifact evidence against their own recorded/effective time contracts; do not join current facts into a historical answer.
• If a source existed but no historical body was retained, return an explicit historical_body_unavailable limitation rather than substituting the live body silently.
• Keep all current visibility, tenant, ABAC, source-count, graph-fact, body-length, and MCP rate-limit bounds.

Response provenance

Each citation must expose enough structured metadata to distinguish:

• source identity;
• source revision/snapshot identity;
• evidence available time;
• requested knowledge cutoff;
• whether the live source has changed after the cutoff;
• any unavailable historical channel.

The synthesized answer must state whether it is fully cutoff-grounded, partially cutoff-grounded, or live-only. It must never call a live-only answer an as-of answer.

Browser and MCP parity

• Browser Global Ask and authenticated MCP use the same cutoff-aware source assembler.
• The MCP input schema and output schema version the new field explicitly.
• Omitting knowledge_cutoff preserves the current live-query contract.

RED→GREEN acceptance tests

1. A post revised after cutoff contributes its retained cutoff body, not its live body.
2. A post created after cutoff is excluded even when its current text matches strongly.
3. Current semantic facts created after cutoff do not leak into a historical answer.
4. Missing historical body returns an explicit limitation and never falls back silently.
5. Two cutoffs against the same source produce deterministic, revision-specific citations.
6. Unauthorized historical revisions remain unauthorized.
7. Browser and MCP produce the same source IDs, revision IDs, cutoff, and limitation flags.
8. Live queries without a cutoff remain backward compatible.
9. Tests distinguish event/effective time from system/available time and prevent future-information leakage.

Scope boundary

Do not combine this with the semantic candidate retrieval patch (#268), MCP admission/CORS hardening (#269), conversation persistence, TEPP estimation, or arbitrary temporal inference. This slice is source selection, revision resolution, provenance, and honest limitation reporting only.

Buyer completion signal

A buyer can ask a dated question and audit exactly which retained evidence existed by that date, while the product explicitly refuses to fabricate a historical view from current data.

[seonghobae]

Draft stacked implementation is #301 (feat/global-ask-knowledge-cutoff-v2230) onto current #264 6c4b1d5eb81e. Exact head 106bc00197c80ffea3d499941d1c2f5c647d8dba. Optional knowledge_cutoff on POST /api/ask uses covering source_post_revision bodies; missing historical bodies are named, never replaced with the live rewrite. Live queries stay live-only. Independent exact-head APPROVE required. Do not self-approve. Does not mix into #287/#290, #276, or #270/#286.

[seonghobae]

Current implementation head is now PR #301 at 7a5fc4b; backend and frontend checks are green. This supersedes the older SHA in the prior issue note, but formal exact-head approval and protected merge remain outstanding.