Rewrite SPEC.md as a full normative system specification (+ v0.2 production-hardening spec)

[mosesman831]

What

Replaces the previous high-level SPEC.md (a ~150-line brand/architecture overview) with a complete, normative specification of every aspect of the Axion Worker, written against the actual code in src/, then extends it with a fully specified v0.2 production-hardening milestone and a conformance-invariants appendix. No code changes.

Part 1 — full normative spec of the shipped system (spec 1.0.0)

• Contracts made explicit for the first time: route evaluation order and exact match rules; the auth resolution algorithm with the upstream header allowlist; the full proxy request lifecycle including which error responses carry x-axion-session; SSE detection, tee semantics, SseLineParser record/field rules, and UTF-8 decoder flush requirements; the background-extraction never-break-the-proxy contract.
• Lens fully specified: all 13 patterns with their regex sources, types, baselines and capture semantics; the scan → sort → dedupe → confidence → shape pipeline; the additive confidence algorithm with clamp bounds, the 80-char marker window, and worked examples.
• PolyVerdict fully specified: trigger precedence and the malformed-header fallthrough, the enforce loop step-by-step, request mutation rules, fence-stripping and balanced-span JSON extraction, the supported schema-keyword table, a complete type-coercion matrix, union-type handling, error message formats, the exact retry-hint text, both provider success shapes, and the 422 contract.
• State layer: DO internal API, storage schema, consistency/ordering guarantees, and the single-key 128 KiB growth ceiling called out as a normative limitation.
• Operational sections: complete error-handling matrix, security threat model, latency table, numeric-constants table, observability, testing/CI, and a compatibility/versioning policy.
• Planned layers (§26): concrete non-normative design sketches for Loop, Gate, the belief graph, and semantic PolyVerdict — clearly marked as having no runtime.

Part 2 — v0.2 production-hardening specification (spec 1.1.0, §27)

A new major section specifying the next milestone to implementation precision — normative when built, nothing implemented today. Governed by five explicit rules (default-off, additive-only, invariant-preserving, fail-open on infra / fail-closed on auth, invalid config never breaks requests):

• Access control: beliefs-API read key with constant-time comparison and dashboard key flow; proxy access keys closing the open-relay gap; admin key + DELETE /api/beliefs/:id.
• Rate limiting: token-bucket algorithm in a dedicated Durable Object, client identity ladder, fail-open budget, 429 shape, and x-axion-ratelimit-* headers.
• Storage v2: per-batch keys removing the 128 KiB session ceiling, retention count cap with truncated disclosure, TTL via DO alarms, lazy idempotent v1→v2 migration, and privacy controls (AXION_STORE_RAW_TEXT, x-axion-no-store).
• Read API v1.1: cursor pagination, since/type/minConfidence filters, O(page) reads.
• Ops: /healthz; a structured log-event schema with a full event table and redaction rules; Analytics Engine metrics; HMAC-signed webhook export with at-least-once semantics and an OTel attribute mapping.
• Surface growth: CORS allowlist + preflight; OpenAI Responses and Gemini adapter specs; dashboard v2 (live polling, recent-sessions MRU, offline vendored React, search/export, a11y).
• Enforce hardening: per-attempt timeout, attempt-count override header, outcome headers, usage aggregation across attempts, schema size cap; plus request body/session-id limits and a consolidated v0.2 route table.

Part 3 — Appendix C: conformance checklist

Twenty testable invariants (I1–I20) of the shipped system — zero-buffering, no Bearer undefined, header allowlist, session-header echo rules, enforce idempotency, DO-id non-leakage, UTF-8/SSE correctness, log redaction, no-invalidation-claims — each cross-referenced to its normative section and suitable as a standing regression test.

Companion doc updates

• TECHNICAL.md and SPEC-PolyVerdict.md defer to SPEC.md as the normative source; README.md points to it.
• Existing threat-model and known-constraint entries now cross-reference their specified §27 remediations.

BUILD-SPEC.md remains untouched as the locked product-decision record; the spec is consistent with D1–D8, and §27 explicitly notes that BUILD-SPEC non-goals bind the current build while §27 defines the next milestone's contract.