Implement optional Blob and secure document modules with unified view preparation

Problem and ownership

Existing runtime/reference AEAD entity support and object-storage providers do not supply the planned independent reference artifacts or transactional Blob lifecycle. Own lightweight contracts, secure implementation extraction and explicit assembly, BlobRef codecs/capabilities, Blob upload/catalog/transaction/retention services and file/S3 adapters, generic authorized prepare, database-backed document snapshot/open/accept and versioned selection integration. Keep Java 17 and runtime framework independence, existing serialization behavior and commit/audit semantics. Verify JDBC transaction identity, four standalone consumers and optional host bridge.

Scope and compatibility

Implement the 2026-10-25 server handoff for independent teaql-blob-reference / BlobReferenceModule, independent optional teaql-secure-document-reference / SecureDocumentReferenceModule, and runtime-owned ViewPreparationService.prepare(ctx, result, viewOptions) returning a presentation copy. Source baselines and actual results will be retained as non-secret execution evidence.

Preserve document="application.docx" and multi-suffix samples. BlobRef stores a stable opaque Key with a text SQL codec; format sets are not ordinary candidates. Storage returns the complete temporary URL and actual expiresAt. Preserve the existing tqr1/tqd1 protocol, key derivation, Actor/scope/purpose authorization, loaded/writable/relationship rules, mutation intent and audit. Existing governed applications cannot downgrade. New selection/binding snapshots need an independently versioned protocol. Source import/API changes require consumer regeneration/migration.

No framework dependency in core or reference modules. Four combinations (base, Blob only, secure document only, combined) must work from Java/Rust terminal consumers. No model-score-driven loading, transcoding/thumbnails, cross-route atomic binding, cross-scope sharing or implementation claims for the remaining five languages. Unsupported generation targets fail explicitly.

Acceptance and evidence

Follow R0–R8 of reference-modules-server-implementation-plan.md; retain exact source revisions, toolchains, model/fixture hashes, commands, environment class, failures and skips. Never record secrets, full tokens or signed URLs.

R0: independent default-branch checkouts, actual repository instructions, existing baseline results and isolated resource inventory.
R1: unambiguous Blob field/profile/metadata/binding contracts, requiredCapabilities, PreparedView/optional DocumentContext, errors, defaults and real-file fixtures (JPG/JPEG, PNG, MP4, MP3, DOC/DOCX, XLS/XLSX, PDF).
R2A/B: optional secure module extraction with protocol regression tests; lossless KSML recognition and compiling Java/Rust types, SQL codecs, metadata and capability declarations. String, URL, JSON and ordinary candidates regressions.
R3/R5: uploads, authoritative content detection, immutable metadata, profile snapshots, catalog/binding schema, atomic same-physical-PostgreSQL-transaction participant; graph/ledger/outer transaction, retries, failures, concurrent binding/GC, replace/clear/cascade/shared/unloaded state and retention promises. Outer Rust transaction remains caller-owned.
R4/R5: current authorization fixes the visible graph before document and Blob stages; no repeated issuance, hidden-field signing, dirty entities or URL persistence. URL is not a write credential; governed selection binds Actor/document/field/target and resolves to BlobRef before atomic save. Java document open/accept/snapshot requires actual database evidence, beyond Rust's retained memory POC.
R6: clean generated Java/Rust workspaces compile and run; CLI and optional Spring/Axum behavior agree; real S3 full-URL external GET, MIME/filename, audio/video Range and expiry verification; complete applicable regressions.
R7: immutable internal candidates, registry-only clean consumers (no source replacement/cache bypass), matching generator staging, checksums and schema/deployment migration and rollback rehearsal.
R8: final internal revalidation, authorized public artifacts and signed tags, clean public consumers, deployed generator output and issue closure only for demonstrated scope.

R6 implementation, R7 internal qualification and R8 formal delivery are separate milestones. Public release and production deployment remain subject to existing governance/authority. Missing external resources must not stop independent implementation and must never count as acceptance.

Primary coordination issue: https://github.com/teaql/teaql-conformance/issues/237