fix: retain a version ledger for uploaded originals

[virtue039]

Successful multipart uploads could not serve their original content: upload inserted a document without a document_versions row, while GET /documents/{id}/content requires the current digest in that ledger. Both real-model acceptance runs reproduced this for every uploaded document (16 total), although the original blobs were retained.

Uploads now commit the document, version 1 and processing job in one transaction, using the existing sync ingestion transaction helper while preserving upload date provenance. Reuploading a soft-deleted original restores the same document and version and queues processing atomically. Queue failure rolls back both new creation and restoration; active duplicates still skip without queuing another job.

Migration 0111 records the current digest, size and document date for retained documents with no version ledger. Its ingestion timestamp is the repair time: it does not reconstruct missing historical revisions or original ingestion times. Existing ledgers and purged documents are left untouched. The CLI schema version is bumped to 100, matching the migration file count. This repairs the existing content API contract without changing its response shape.

Validation:

• The expanded upload regression test fails against the original production code (versions.len(): 0 instead of 1) and passes with this change.
• Required live PostgreSQL/pgvector workspace tests: 1,500 passed, 0 failed, 6 existing ignored. UTOPIA_TEST_REQUIRE_DB=1 and UTOPIA_TEST_REQUIRE_PDFTOTEXT=1; all new tests ran, including queue rollback, restoration and idempotent migration repair.
• cargo fmt --all --check, locked workspace/all-target Clippy with -D warnings, locked workspace tests and server build passed.
• Frozen-lockfile web install and production build passed.
• Upgraded isolated copies of both prior acceptance databases using normal server startup migration. All 16 uploaded documents served byte-identical originals through both current and explicit version-1 endpoints (32/32 HTTP 200 reads), with document metadata unchanged and one recorded version each. Original databases were not changed; model configuration was disabled in the copies and this storage replay made no model calls.

The separate negative-case design PR #1203 and the observed alignment, literal extraction and end-date failures remain outside this bugfix. Latest main/dev migration numbers were checked before submission.

[WaylandYang]

Thank you for finding this. I confirmed it on a local rc9 database: three uploaded documents, none with a version row, and the content route answers 500 for each.

The change is right for multipart upload and its tests pass here on a fresh database. One path is still open, the JSON push (POST /kbs/{id}/ingest, through documents::create), which writes no version either; it is small, so we will close it in a follow-up of our own.

Merging. Thanks again.