test: compare access decisions across the two storage layouts #1870

[DmytroZaichenkoDev]

Stacked on #1891.

Seeds durable state — an owned resource, a read share, a write share, a published resource, a pending review copy, an application, app data — then asks 21 access questions of both layouts and compares the decisions.

Questions go over HTTP rather than into AccessService directly: populatePermissions runs the same eleven-rule chain and puts its result in the response, so this observes the real chain with a real context. A hand-built context would mostly prove the mock was set up the way the test expected.

Coverage — 10 of the 11 rules, each with a grant and a denial:

getOwnResourcesAccess   getAdminAccess       getGlobalReaderAccess
getAutoSharedAccess     getPerRequestPermissions
getAppResourceAccess    getReviewAccess      getPublicAccess
getSharedAccess         getAppSelfAccess

The 11th, getOwnResourcesAccessForChainedSchemaRichApplication, needs context.getDeployment() to be a schema-rich Application, and only the deployment-routing controllers set a deployment — ResourceController does not. It is listed under uncovered with that reason, and the matrix declares the whole chain, so a rule that is neither covered nor explained fails the run.

Each cell declares the permissions it must yield, and some what it must not. Without that a matrix that stopped exercising the chain would compare denied-to-denied and report the layouts identical.

Result is clean, as expected — shares and rules key on logical urls and bucketLocation stays legacy, so the inputs never change. Worth building anyway because the same differ answers "does the new engine decide identically?" when the chain is replaced in P3, and it has to exist while there is still a working reference implementation to capture behaviour from.

Found api_key_data/ unmapped on its first run — per-request keys threw, taking out every application caller. Fixed in #1889.

🤖 Generated with Claude Code