feat(records): govern lifecycle recovery and transfer evidence

docs/EAKTE_ARCHITECTURE.md

@@ -17,8 +17,8 @@ Implementation is tracked in
 
 ## Implementation Status
 
-The native foundation is implemented through the work packages tracked by
-Records #2-#4:
+The native foundation and governed lifecycle are implemented through the work
+packages tracked by Records #2-#6:
 
 - versioned file plans and record classes;
 - stable records, immutable revisions, volumes, exact record items, and
@@ -29,13 +29,24 @@ Records #2-#4:
   temporal status, create/edit, and filing actions;
 - a provider-neutral Core filing contract with exact Files-version and
   Cases-revision providers.
+- governed close/reopen transitions, class-bound retention calculation,
+  effective-dated holds, appraisal, evidence-bound disposition proposals, and
+  mandatory independent approval before finalization;
+- archive-neutral transfer manifests and bounded receipts, plus an explicitly
+  non-conformant simulation provider that never claims custody;
+- durable recovery-ledger fences for every API write, atomic domain/checkpoint
+  commits, Audit events, source-revision revalidation, transfer-manifest
+  checksum checks, and an operator recovery-evidence view;
+- tenant administration for versioned file-plan nodes and record classes,
+  explicit volume management, and lifecycle controls in the eAkte workspace.
 
-The remaining delivery order is intentionally visible rather than implied:
-Records #5 owns closure, retention, holds, appraisal, and disposition; #6 owns
-recovery and signed evidence; #7 requires selection and target testing of an
-archive/xdomea provider; and #8 proves the reference journey. Restricted
-per-record access grants also remain a dedicated access-policy slice. No
-archive or destructive effect is currently claimed.
+The remaining boundary is intentionally visible rather than implied: Records
+#7 requires selection and target testing of an archive/xdomea endpoint and
+conformance profile; #8 completes the cross-module reference journey and
+production evidence. Restricted per-record access grants also remain a
+dedicated access-policy slice. Destruction is represented only as an approved
+pending state; no content deletion or real archive effect is currently
+claimed.
 
 ## Ownership Boundary
 
@@ -103,10 +114,15 @@ planned -> open -> closed -> retention_running -> appraisal_due
                                                    destroyed
 ```
 
-Reopening creates a governed transition and does not reset elapsed retention
-without an explicit rule. A hold preserves the reason and affected scope. A
-destruction action requires exact manifest, current authority, policy,
-approval, preflight, idempotency, outcome-unknown recovery, and evidence.
+Reopening creates a governed transition and preserves the preceding retention
+schedule. A later closure only restarts retention under an explicit
+administrator action. A hold preserves reason, authority, scope, effective
+interval, policy references, and release evidence. Holds block proposal,
+approval finalization, packaging, and dispatch. A destruction approval changes
+the record to `destruction_pending`; no source object or content is deleted.
+An unapproved disposition can be withdrawn through a new immutable revision so
+a corrected proposal can supersede it. An approved disposition cannot use this
+correction path.
 
 ## Filing Semantics
 
@@ -189,10 +205,17 @@ available in an evidence/details view.
   storage or an external provider, never node-local paths.
 - Every external filing, transfer, or destruction uses intent-before-effect,
   idempotency, durable receipts, outcome-unknown state, and reconciliation.
+- Native Records API writes use a per-resource distributed lease and the Core
+  recovery ledger. Immutable revision, chronology, Audit projection, and the
+  terminal checkpoint commit atomically.
 - Backup evidence binds record rows, object manifests, provider mappings,
   policy/configuration versions, and key references.
 - Restore verifies content digests, missing keys/objects, provider reachability,
   and disposition holds before reopening effects.
+- Automated evidence tests prove that terminal Records operations and their
+  hash chain remain verifiable after a database backup/restore round trip. An
+  outcome-unknown transfer is persisted as non-retryable and cannot advance
+  custody or record disposition state.
 - Search indexes are rebuildable projections and cannot become record
   authority.
 
@@ -203,8 +226,10 @@ available in an evidence/details view.
 2. Integrate filing from Cases, Forms Runtime, Decisions, Campaign/Postbox,
    Files, and Reporting.
 3. Add closure, retention calculation, holds, appraisal, and reviewed
-   disposition without destructive provider effects.
+   disposition without destructive provider effects. **Implemented.**
 4. Add native transfer packages and one target-tested xdomea/archive provider.
+   Native packaging and simulation are implemented; target selection/testing
+   remains external.
 5. Add destruction/recovery, TR-ESOR provider integration, migration, and
    signed reference-journey evidence.
 

docs/RECORDS_DOMAIN_BOUNDARY.md

@@ -42,16 +42,24 @@ The native kernel currently provides:
   file versions and Cases revisions;
 - tenant APIs, search projection, uninstall/retirement guards, and a Records
   workspace using shared WebUI controls.
+- immutable close/reopen, retention, hold, appraisal, and independently
+  approved disposition transitions;
+- archive-neutral manifests, bounded receipts, and a clearly marked transfer
+  simulation that does not claim custody;
+- Core recovery-ledger adoption, atomic terminal evidence, Audit projection,
+  source and package restore diagnostics, catalog administration, volumes, and
+  lifecycle UI.
 
-Restricted object grants and the lifecycle after the planned/open stages remain
-separate governed slices. Archive transfer and destructive effects are not
-implemented by this kernel.
+Restricted object grants remain a separate governed slice. A target-tested
+archive adapter and any destructive effect remain deliberately unimplemented;
+approved destruction is only a pending lifecycle state.
 
 ## First Implementation Slice
 
-Complete restricted access, closure and retention calculation, holds,
-appraisal, disposition, transfer, recovery evidence, and one target-tested
-archive provider without moving source-module ownership into Records.
+Complete restricted access and one target-tested archive provider without
+moving source-module ownership into Records. Extend the executable reference
+journey across assisted service, decision, filing, hold, restore, search, and
+archive simulation before claiming production maturity.
 
 The complete native/external boundary, temporal and purpose-aware record model,
 disposition lifecycle, German public-sector provider profiles, and staged