Reject corrupted placement rows before owner lookup

Author: KSemenenko

README.md

@@ -357,13 +357,16 @@ pass in both normal and scalar modes, and three FTS process-recovery scenarios
 pass. The native inventory contains 3039 tests. Exact-source Linux RF3 and complete
 acceptance gates remain open; these additions do not increase the accepted task count.
 
-The latest correction preserves exact failure diagnostics for individual replica
+The quorum correction preserves exact failure diagnostics for individual replica
 discovery and returns `NoLeader` when the compatible voters cannot form a quorum.
-The current local solution build and formatter pass, and nine complete cohort
-flows pass in both normal and scalar modes. RF3 container rejection now reports
+Its nine complete cohort flows passed in both normal and scalar modes. RF3 container rejection now reports
 the first failed admission check while retaining every original predicate. The
-full Linux normal and scalar unit steps for the prior source failed; their
-original reports and current RF3 qualification are still pending.
+latest correction validates malformed placement rows before unnecessary owner
+lookups and reports unregistered committed owners as corruption. The current
+local solution build and formatter pass, and 73 placement, owner-registration,
+graph and query flows pass, including both original Linux unit failures. The
+prior complete Linux run passed 3037/3039 unit cases in both modes and 270/270
+recovery cases. Exact-source Linux full-suite and RF3 qualification remain open.
 
 Complete product functional coverage remains **unmeasured**. The
 [coverage contract](docs/Features/CodeQuality.md) admits whole operation flows,

docs/ADR/ADR-101-explicit-atomic-partition-placement.md

@@ -69,3 +69,9 @@ flowchart TD
 ```
 
 Ownership movement and current same-view session tokens retain the contract in [ADR-017](ADR-017-ownership-session-tokens.md). Unknown or unverifiable lineage invalidates explicitly.
+
+## Original Linux corruption correction contract, 2026-10-08
+
+TASK-PMAP-CORRUPTION-ORDER-001 implements the existing REQ/AC-PMAP-001 and REQ/AC-PQUERY-003 failure contract. Ordered stages: root first freezes this amendment; separates decoded row-shape validation from complete same-view owner-tuple validation in `ClusterRouting/Validation/AtomicPartitionPlacementValidation.cs`; applies shape validation in both bounded `Serialization/AtomicPartitionPlacementSerialization.cs` row readers before owner lookup; and supplies an explicit internal missing-owner failure category to the existing resolver. `RegisteredAtomicPartitionPlacementReader.cs`, `AuthorizedQueryAtomicPartitionPlacementReader.cs` and `GraphTraversal/Validation/DatabaseEngine.GraphCrossPartitionPlacement.cs` use `Corruption` for committed references; `Commands/AtomicPartitionPlacementBinding.cs` retains `UnsupportedCapability` for a proposed target. No new dispatcher, provider, stored format, alias/field ID, schema, topology, limit or compatibility path is introduced.
+
+Root runs the existing real ZoneTree corruption flows with their exact no-mutation oracles plus placement, owner-registration, graph and query regressions, solution build and formatter. Original b68 Linux normal/scalar failures and recovery270/270 are retained. Delivery commits the completed correction on main, then requires exact-source Linux full suites and genuine Aspire RF3; local development passes cannot close this ADR or any task. No data conversion or automatic repair is performed; rollback uses the existing verified source/backup procedure without redefining a committed row.

docs/Features/ClusterRouting/AtomicPartitionPlacement.md

@@ -52,3 +52,9 @@ flowchart TD
   CAS -->|fallback lookup| Witness[Return default tuple, fallback=true, revision=0]
   Pair --> Commit[Commit once through existing ZoneTree apply gate]
 ```
+
+## Persisted placement corruption correction, 2026-10-08
+
+TASK-PMAP-CORRUPTION-ORDER-001 preserves REQ/AC-PMAP-001 and REQ/AC-PQUERY-003 under ADR-101. Validate a decoded row's version, full key identity, nonempty physical owner, positive revision and present voters before resolving its registered owner. A persisted row selecting an unregistered owner is `Corruption`; a new bind request proposing an unregistered owner retains `UnsupportedCapability`. Valid registered owners retain their complete incarnation, ordered voter and epoch checks. Each actual metadata read remains charged before decode; no budget, read cut, authorization, fallback or stored bytes change.
+
+Root owns the existing Core ClusterRouting row validation/serialization, registered and authorized placement readers, bind selection and GraphTraversal placement call site. The unchanged real-store `AcPmap001OwnerTupleMismatchFailsReadAndBindAsCorruption` and `AcPquery003MalformedCatalogDirectoryAndRowFailClosedWithoutMutation` are the regressions. Preserve their exact failure categories and unchanged-state assertions, then run the broader placement, registered-owner, graph and query flows. The original Linux b68 normal/scalar failures remain evidence until a later exact-source required run qualifies the repair; no task closure is asserted here.

docs/Features/QueryExecution/DistributedQueryExecution.md

@@ -279,6 +279,8 @@ This stage publishes a typed multi-partition request over the already implemente
 
 ## REQ/AC
 
+TASK-PMAP-CORRUPTION-ORDER-001 refines existing REQ/AC-PQUERY-003 without changing grants or public shapes: malformed decoded placement identity fails `Corruption` before an unnecessary registered-owner lookup. An unknown owner referenced by a committed row is corrupt state, while an unknown target proposed by a new bind remains `UnsupportedCapability`. All actual reads retain their original byte/attempt charges, same-view authorization and exact owner-tuple validation. The two original Linux corruption regressions and broader placement/query flows must pass; source presence is not qualification. See the correction in [AtomicPartitionPlacement](../ClusterRouting/AtomicPartitionPlacement.md) and ADR-101.
+
 - REQ-PQUERY-001: expose a bounded generated request that carries only up to eight full atomic `PartitionRef`s, one existing `SelectQuery`, existing query parameters, full-scan opt-in, and AST version. AC-PQUERY-001: reject default/empty/over-eight or duplicate partitions, invalid AST version/shape, oversized request, cursor-bearing or otherwise unsupported query semantics, `Explain`, and non-null `ModelSource` before any storage read; do not accept caller identity, roles, cut, owner/catalog witness, read grant, physical placement, or deadline.
 - REQ-PQUERY-002: retain the native persisted-authority and catalog fence. AC-PQUERY-002: each SDK/MCP call follows signed request verification, native request identity validation, `NativeRequestWorkOwner` admission, the existing quorum `ReadBarrierAsync`, request freshness validation, persisted `GrainRequestAuthority.Reload`, and normal `GrainQueryReadCapabilities` execution. No admin-only `ReadPhysicalShardCatalog` or `ReadAtomicPartitionPlacement` public API is invoked for a non-admin. The node startup/per-request catalog admission fence remains the authority that the local server is a current member of the configured physical owner.
 - REQ-PQUERY-003: bind each authorized leaf to the canonical placement visible in that same leaf's native `Store.Read`. AC-PQUERY-003: call the internal placement view reader only *inside* the existing `WithQueryView` callback, after it has loaded persisted principal and passed `Authorization.Require(Query | DocumentsRead)` for that leaf's partition/collection. That internal helper reads and validates SCAT plus descriptive PMAP from the provided `IKeyValueView`, performs no principal/admin check and no separate `Store.Read`, and returns only an internal typed owner witness. Compare its full physical-shard ID, incarnation, exact ordered voters and placement epoch with the server-owned expected local physical-owner tuple supplied by the authenticated DatabaseReadGrain composition; validate each row/fallback revision against its own same-view directory and row; valid leaves may differ in row revision and fallback state. Same-tuple placement is supported. A valid assignment to another physical owner fails `UnsupportedCapability` in this stage; corrupt/inconsistent catalog/placement fails `Corruption`; a catalog tuple that no longer matches this node's expected owner fails `OwnershipLost`. No fallback or refresh of malformed/mismatched PMAP records.