bug: Experience reads can return content written after custom-policy revocation #2017

Describe the bug

An in-flight shared Experience read on SQLite can return a revision written after access was revoked when a configured custom authorization provider does not read through the content database connection.

The runtime enters a consistent_snapshot=True transaction, but SQLite has not pinned its content snapshot before service.get() checks authorization. The first Artifact table read happens afterward. An allowed decision captured before revocation can therefore be combined with content committed after revocation.

This is a standalone follow-up to the reviews of #1882. The final review confirmed that the defect also existed in that PR's base; it is not a new regression introduced by #1882.

Evidence:

• Reproduction and content-pin control
• Final re-review confirming the outstanding baseline defect
• Runtime transaction and call to service.get
• Authorization before Artifact content retrieval
• SQLite consistent-snapshot transaction handling

Steps to reproduce

Use actual SQLite with independent reader/writer connections and a controlled custom authorization provider. The provider must not incidentally pin the reader's content snapshot by reading from its connection.

1. Create an Experience with revision 1 and allow the reader to access it.
2. Start a read through runtime.artifact_merge.for_scope(scope, "experience").get(...).
3. In the custom provider, capture an allowed authorization decision and pause before returning it. Use synchronization barriers to ensure that Artifact content has not yet been read.
4. While the read is paused, revoke the reader's access and commit a replacement revision 2 through a separate writer connection.
5. Resume the provider with the previously captured allowed decision and observe the in-flight read's result.
6. Perform a fresh read after revocation.

The linked review reports this exact interleaving with a local custom-provider probe. It does not provide a complete standalone script; these steps describe the required deterministic regression scenario.

Expected behavior

An authorization decision captured before revocation must not authorize content written after revocation. Under the existing snapshot-read model, the in-flight read should return the pinned revision 1. Rejecting the read after revalidation would also avoid disclosure, but returning revision 2 must not be possible. A fresh read after revocation should be denied.

Pin the content snapshot before the policy check while preserving the configured custom provider and deferred audit behavior. A regression test should coordinate the interleaving explicitly and assert the returned revision as well as the denial of the subsequent read.

Actual behavior

The paused read returns revision 2, which was written after access was revoked. A fresh read correctly raises AccessDeniedError.

In the linked review's control, adding only an Artifact-head table read before authorization caused the same interleaving to return revision 1. Entering the transaction/savepoint alone did not establish that content snapshot.

Environment

• Database in the original reproduction: actual SQLite.
• Authorization: controlled local custom provider; not an external policy-service or HTTP-route test.
• Last reviewed PR head: b402e590ab9244897d91123fc482e0c0cc770a9a.
• Base where the same defect was confirmed: a72f223b88a341162618686a404e29d5f2290994.
• The same authorization-before-content-read path was found during post-merge inspection of master on October 15, 2026.
• Exact SQLite, Python, and operating-system versions were not specified in the linked review.
• This report was drafted with OpenAI Codex from the linked reproduction evidence and source inspection. No new concurrency reproduction was run while filing it.

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.