e2e: improve pi-deferred-compaction-marker scaffolding (still skipped)

Per Oracle investigation (bg_e4d4c044) of the v0.21.5 release-blocking
skip:

1. Pressure math fix: the original test set both input_tokens AND
   cache_creation_input_tokens to 90_000, producing ~180% pressure
   against a 100_000 token limit (Pi pressure counts input + cacheRead
   + cacheWrite per pi-pressure.ts:80-93). That routed the next pass
   through the ≥95% emergency recovery path, adding latency and
   unrelated behavior. Now uses a single 90_000 input bump with zero
   cache_creation to stay at ~90% — clearly above the 40% execute
   threshold, clearly below the emergency cliff.

2. Stable checkpoint: replaces waitFor on
   pending_pi_compaction_marker_state (a transient internal queue
   cleared by the next drain pass, so racing against it is
   unreliable) with waitFor on the durable Pi compartment row in the
   compartments table. Matches the pattern
   pi-historian-success.test.ts uses with a 300s budget for Pi
   historian e2es.

3. Comprehensive FIXME: documents BOTH the original skip reason and
   the Oracle-recommended fix attempts so future investigation has a
   real baseline. The test still fails in the e2e harness with the
   improved scaffolding (the durable compartment row also doesn't
   appear within 300s), so the suspected cause is harness-level:
   Pi 0.74 RPC-mode subagent behavior, mock-provider historian
   matching, or test-warmup pressure interaction. Needs focused
   investigation rather than another assertion adjustment.

Production drain logic remains covered by unit tests in
packages/pi-plugin/src/compaction-marker-manager-pi.test.ts plus the
storage-meta-persisted integration tests, and is verified live in
user dogfooding. No production change in this commit.