IPCrypt: erase submit must not create the policy marker #3109

Part of epic #2993. Bug introduced by PR #3093 (#3049), found by its opus checkpoint review.

ravel-cli erase submit --ipcrypt-config creates sys/ipcrypt/policy when the marker is absent and the policy is non-empty. The decision 8 check runs through check_marker_logged (services/ravel-cli/src/erase.rs, around line 383), which goes to check_marker's create-if-absent path.

Two harms follow:

• No process ever wrote data under that policy, so every encrypted matcher matches nothing and the erasure reports success on zero records.
• The new marker makes every ingesting ravel-server without the policy refuse at its next start.

Until this lands, do not run erase submit with --ipcrypt-config against a bucket that has no sys/ipcrypt/policy marker.

Fix

The behaviour is set by the ADR-2993 erasure amendment of 2026-10-19 (PR #3101), second bullet.

• With an absent marker and a non-empty policy, erase submit never writes the marker.
• It refuses a request that carries at least one matcher that would be encrypted. The message says the bucket's data was written without the policy, so the erasure should be submitted without --ipcrypt-config.
• A request with no matcher that would be encrypted proceeds, and writes no marker.
• A present marker keeps today's checks: refuse on a mismatch or on any read failure.
• An absent marker with an empty policy proceeds, as today.

This fix covers only the marker behaviour. The --plaintext-matcher flag and the other review follow-ups stay in #3108.

Acceptance tests (services/ravel-cli)

• An absent marker plus a non-empty policy plus an encrypted matcher is refused. Assert that no marker and no request object are written; FaultStore or MemoryStore listing is fine.
• An absent marker plus a non-empty policy plus only matchers on keys with no rule succeeds and writes no marker.
• The existing mismatch and read-failure tests still pass.