persist v50: withdrawn_by re-derives stored withdraws through the WRITE-form check (now a 5-hop default) — use check_withdraws_admission_as_admitted (recorded depth) #690

From persist v50.0.0 (CIRISPersist#928 / #925 review). CC 4.1.1's 5-hop default now governs check_withdraws_admission (the WRITE gate). src/drive.rs:1094 (withdrawn_by) re-derives already-stored withdraws at READ time through that same write-form check, so after v50 a withdraws validly admitted through a 6–16-hop chain (pre-v50, or under an explicit opt-in) would read as not admitted and the withdrawn blob would come back live — the retroactive change persist itself ruled out.

Persist v50 records each withdraws row's admitting depth (migration V157, federation_withdraws_admission_depths; pre-V157 rows read as 16) and exports check_withdraws_admission_as_admitted(dir, row), which re-derives at the ROW's recorded depth. Ask: withdrawn_by (and any other read-time re-derivation) calls that helper instead of check_withdraws_admission. Persist's own bytes-plane fold (retiring_composer) already does. Ships with the v50 adopt.