storage: encrypt_and_pin re-seals withheld blobs through unbounded sync reads with no permit or budget #486

Summary

encrypt_and_pin (crates/gitlawb-node/src/encrypted_pin.rs:119-189) re-seals every withheld blob in a loop, reading each object with the synchronous unbounded store::read_object (:155) directly on the async worker, with no batch budget, no pin_semaphore/encrypt_semaphore permit, and no per-request timeout on the Kubo upload. Its twin pin loops were hardened for exactly this (#173/#174: read_object_bounded, spawn_blocking, PIN_BATCH_BUDGET, permits); this loop predates or missed that pass. Reached from the detached post-push task (api/repos.rs:1468, :881-911); plan_seal re-seals on reader-set or tag changes, re-reading every withheld blob.

Impact

A repo owner flipping one reader DID on a repo with many withheld files makes the detached task block a tokio worker per object and flood Kubo with sequential uploads, for hours, with no aggregate bound. Owner-triggered (authenticated), hence not high.

Remediation

1. Port the loop to read_object_bounded + spawn_blocking with the same batch budget and permits as its fix(node): gate GET /ipfs/{cid} tree objects so a withheld subtree's structure can't leak (#135) #173/feat(node,git): cap concurrent served git ops with a 503 load-shed (#62) #174 twins.

Proposed labels: kind:bug, crate:node, subsystem:storage.