Build re-runnable orphan-image reference counter before any sweeper (api-images)

api-images orphan reconciliation (coder-mars-cc + coder-apiimages-cc, 2026-09-05): 256/15583 tenant-mars files (37.1MB, 1.6% by count, 0.15% of 25GB floor) are orphaned - not referenced by practicaImages OR users.profileImageId, accruing slowly/evenly, no burst. Accepted-loss for now, do NOT build a sweeper yet. REQUIRED FIRST: build a counter/reconciliation script that re-runs this join on demand (currently only knowable via a manual one-off join, artifacts at /data-venus/api-images/orphan-reconciliation/2026-09-05/). Acceptance criteria (hard, from a near-miss during measurement): - Must enumerate its reference columns EXPLICITLY (practicaImages.imageId + users.profileImageId at minimum) and FAIL LOUDLY if a new/unknown reference column exists - silent under-enumeration is the failure mode that deletes live data. - First measurement pass omitted users.profileImageId and produced a false orphan list containing 60 live profile photos (avg ~398KB vs ~152KB baseline - a by-count/by-size sanity check alone would NOT have caught this either). - Must key ONLY on real reference columns, never a text search of appEvents/changelog payloads for image ids - an id appearing in a log/audit payload is a MENTION not a reference; keying on it would make those files permanently unreclaimable while looking correct. - api-images has no DB and no reference model and structurally cannot reclaim on its own - any future sweep is Mars issuing ordinary DELETEs with its own key, 90-day trash as safety net. This WI is the counter only, NOT a sweeper - do not build deletion in this WI.