feat: validate project history through TEPP temporal contract (v2.20.0)

[seonghobae]

Refs #279

Purpose after project-history convergence

This PR is the optional LineageWeave ↔ TEPP temporal validation/enrichment adapter for the normalized project-history authority in #283. It is not a second project-event classifier, persistence model, authorization gate, or Buyer timeline authority.

The canonical project identity, event facts, event relations, responsibility intervals, evidence references, visibility result, truncation state, and handover gaps come from #283. This adapter may send only that already-authorized, bounded contract to TEPP and may return coded temporal validation/association metadata without replacing the source facts.

Required contract

• strict versioned LineageWeave ↔ TEPP schema;
• credential-free service request with opaque evidence references and explicit clocks;
• no browser bearer token, provider credential, database DSN, or unauthorized excerpt forwarded;
• exact project identity supplied by feat: add normalized evidence-bound project history authority (v2.18.0) #283 rather than fuzzy or title-derived binding;
• explicit lifecycle event types supplied by feat: add normalized evidence-bound project history authority (v2.18.0) #283 rather than reclassified from arbitrary VOC-family text;
• offset-aware event and knowledge-cutoff timestamps;
• deterministic rejection of malformed clocks, duplicate event identities, unordered results, unpublished fields, theta, causal scores, or unknown schema versions;
• fail-closed behavior when TEPP is unavailable, with the canonical feat: add normalized evidence-bound project history authority (v2.18.0) #283 timeline still readable;
• an explicit availability-basis code until a separate system-availability clock exists.

Authority boundary

• PostgreSQL and feat: add normalized evidence-bound project history authority (v2.18.0) #283 remain authoritative for facts and authorization.
• TEPP validates temporal consistency and may return temporal_association_only or another controlled non-causal code.
• TEPP cannot create a missing event, actor, responsibility interval, project identity, evidence link, confidence, theta, or causal conclusion.
• Event Lineage remains related-history evidence, not causation.
• Contextual Orchestrator remains the prose-answer engine and does not become the numerical or temporal authority.

Stack

#258 → #260 → #261 → #262 → #263 → #264 → #283 → this PR

The branch must be rebuilt or restacked on the exact final #283 head. Any existing independent timeline, project aggregation, event classifier, or responsibility-gap implementation in this branch must be removed in favor of the shared #283 contract.

RED→GREEN and Draft exit

• tests first prove strict request construction from a feat: add normalized evidence-bound project history authority (v2.18.0) #283 payload and reject unauthorized/unpublished fields;
• response parsing proves deterministic ordering, schema/version checking, temporal-only semantics, and fail-closed unavailability;
• integration tests prove hidden evidence cannot affect the TEPP request or returned Buyer metadata;
• complete Python/PostgreSQL/frontend checks, security, SAST, ontology/provenance, coverage, supply-chain, and documentation gates pass on the exact current head;
• repair-only workflows and payloads are absent;
• all valid review threads are resolved and a qualifying independent exact-head approval exists.

Do not self-approve, force-merge, or treat queued/pending/absent checks as success.

[seonghobae]

Superseded by the separated project-history stack. This branch is no longer the bounded #264 → project history slice described in its body: its recorded base is #276's Global Ask public-verification branch and the diff carries SearXNG claim verification, GNB Keyman focus, durable ingestion, organization-resolution, and other unrelated parent changes alongside project history. PR #285 now owns the LineageWeave-native exact-project history/read model and shared Buyer timeline; PR #282 owns the separate TEPP read/Global Ask/post Ask augmentation. Keeping #281 would duplicate both responsibilities and merge an incorrect composite base. Closing without merge; no one-shot workflow or predecessor evidence transfers.