[R-4][Medium] Per-object/owner ACLs for object & LFS confidentiality

[v-code01]

From the review (https://github.com/v-code01/ledge/blob/main/AUDIT.md §F-3, R-4). Cross-tenant object/LFS confidentiality rests on ObjectId-unguessability + ref-reachability, not per-object ACLs; an out-of-band oid leak permits a cross-tenant read of that object. Refs/workspaces ARE isolated. Closes it: per-object/owner ACLs on the object/LFS read paths. Severity: Medium.

[v-code01]

R-4 is now addressed in code (both halves of F-3):

• Git objects (9c3954a): upload-pack authorizes every want against the caller's segment — a want must be an advertised tip or reachable from the segment's refs, over HTTP and SSH. A want for a leaked/guessed id outside the segment is refused with ERR ... not our ref (identical to a nonexistent object → no existence oracle).
• Git-LFS (d5adbec): LFS objects are stored per-tenant (<data_dir>/lfs/tenants/<id>/; root flat). A caller only sees LFS objects it stored; a foreign oid is a 404.

Cross-tenant object/LFS reads no longer rest on ObjectId/oid unguessability. Verified with unit + handler tests and no regression across the real-git/git-lfs e2e suite (clone/fetch/partial/shallow/ssh/lfs). Full per-object owner ACLs (vs. segment-reachability) remain a heavier future option if mutually-distrusting tenants need per-object grants within a segment; closing is at the maintainer's discretion.