b4d691183b
Drives a real unopenable lock path — a directory where the code expects a regular file, so open() raises a genuine kernel OSError — rather than monkeypatching the helpers, standing in for the ENOSPC/EMFILE the field reports hit without needing to fill a disk. Both authorities are covered at the primitive and the behavior level: fts_rebuild_admission refuses admission and rebuild_fts() reports no progress (asserted against a preceding successful rebuild, so the 0 is the deferral and not an unrelated no-op); _cross_process_repair_lock refuses the authority and repair_state_db_schema runs no writable_schema surgery, takes no forensic backup, and leaves the damaged image byte-identical for the next authorised pass. A guardrail test pins that a pathless in-memory store is still admitted, so the fix cannot turn that legitimate no-op into a permanent deferral. All four deferral assertions fail on the pre-fix code, where the repair test shows the surgery really did proceed without cross-process authority.