carlos / platform Public

objstore+console: three more tests that read a Deny as the Deny

CI caught one of these and the other two were sitting behind it, silent.
I had reported the previous commit as passing every package; the run I
read exited 0 but predated the change. That is the same mistake as the
one this branch has already paid for once — trusting an exit code
instead of the thing it was supposed to have covered.

TestScanEnforceWritesTheDenyToThePolicy asserted that granting the store
wrote NO deny and that `enforce on` wrote one, both by searching the
policy for `"Effect":"Deny"`. The anti-forgery pair is unconditional, so
the first assertion now failed and the test was right to fail: it was
measuring the wrong thing and only noticed because the wrong thing
changed.

The two beside it are worse, because they are POSITIVE assertions:

  TestGrantWritesDenyOnHealthyStore    "did not write the deny"
  TestGrantClearsDenyWhenEnforceIsCleared  "setup: the deny was never written"

Both would now pass with the enforcement hoist entirely removed — the
anti-forgery Denys satisfy the search on their own. A green test
asserting nothing, in the exact place the hoist is the only thing being
tested. Nothing failed, which is why they needed looking for rather than
waiting for.

All three key on s3:ExistingObjectTag now, which is what "enforcement"
actually means in a policy document. Mutation-tested rather than
asserted: with the hoist in walk.go disabled so rec.Scanning.Enforce
never reaches EnsureUser, both tests fail with their own messages. The
old assertions would have passed.

And two of them gain the mirror they were missing — that turning
enforcement off does NOT take the anti-forgery Denys with it. A store
that has stopped denying infected reads is exactly where a forged clean
tag would sit unnoticed longest.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PEkJh1ESqiA84quAHJV4K6