followup-blob-ispublic-strip: remove legacy isPublic read-side strip once Cosmos is verified clean (PR #446)

[geevensingh]

Context

PR #446 (1.3.0) removed the isPublic blob visibility flag end-to-end. Per DESIGN_SPEC Schema evolution -> Removal playbook, a read-side strip was added in api/src/shared/blobs.ts normalizeBlobDocument so legacy stored documents carrying isPublic never round-trip the field on the wire, and emit a deduplicated blob.legacy.isPublic.stripped telemetry event the first time each blob id is touched per Functions-instance lifetime.

This issue tracks removing the strip + the telemetry event + the test seam once Cosmos is verified clean.

Code to remove (when ready)

In api/src/shared/blobs.ts:

• The MAX_STRIP_LOGGED_IDS constant and the stripLoggedIds Set (and their JSDoc).
• The Object.prototype.hasOwnProperty.call(doc, 'isPublic') guard branch inside normalizeBlobDocument (the entire branch becomes dead).
• The __resetIsPublicStripLoggedIdsForTesting exported test seam.
• The BlobDocument & { isPublic?: unknown } type intersection on the normalizeBlobDocument parameter (revert to BlobDocument).

In api/src/shared/blobs.test.ts:

• The entire normalizeBlobDocument legacy isPublic strip (1.3.0) describe block (6 tests).
• The __resetIsPublicStripLoggedIdsForTesting() import + beforeEach call.

In src/app/core/telemetry/telemetry-message-ids.ts (frontend literal-union catalog -- DOES NOT live in the api workspace; just noting in case operators ever query):

• Nothing on the frontend side; blob.legacy.isPublic.stripped is a backend-only event that does not appear in the frontend telemetry catalog.

Exit criterion

Cosmos must be verified clean before removing the strip. Either:

Option A (passive, recommended): monitor the blob.legacy.isPublic.stripped event count in Application Insights. When the count is 0 for N consecutive days across all Functions instances (suggest N >= 30 to absorb cold-start tails), Cosmos can be assumed clean and the strip is safe to remove. Caveats:

• The strip dedupes per blob id per process lifetime, so a steady-state non-zero count means there are blobs in Cosmos that were last written under v1.0.x and have not yet been re-saved. The number trends to zero naturally as users update / re-save / delete legacy blobs.
• The cap at 10k unique ids per process means if the legacy population is larger than 10k unique ids, the signal will saturate at 10k per process per lifetime; the cap itself proves the population is non-trivial, but reading the cap doesn't tell you exactly how many remain.

Option B (active, faster): run a one-shot migration script (template at api/scripts/migrate-example.mjs) that reads every blob and re-saves any straggler in the legacy shape. After running, Cosmos is clean immediately and the strip can be removed in the next deploy.

Related

• PR 1.3.0: remove isPublic blob visibility flag #446 (1.3.0 merge):
• DESIGN_SPEC Schema evolution -> Removal: search for "Removal. Treat as a rename to nothing"
• DESIGN_SPEC 1.3.0 history entry: search for "1.3.0: Remove the isPublic blob visibility flag"

Branch-name hint

followup-blob-ispublic-strip (matches the placeholder referenced in DESIGN_SPEC and api/src/shared/blobs.ts JSDoc).