availableLanguages: removing a child correctly drops a stale language

[tanflem]

Parent

Sub-issue of #9515 (Rebuild Video.availableLanguages as one cycle-safe, recursively-correct source of truth).

What to build

Removing a video from a container's children correctly drops a language it uniquely provided from that container's availableLanguages. Today, removing a child fires reconciliation for its variants, but by the time that reconciliation runs the parent-child relation is already severed, so the old parent is structurally unreachable through the normal path and the stale language sticks forever.

videoUpdate's child-removal handling is changed to explicitly recompute the old parent (using the engine from #9517) after the relation is severed, and cascade that recompute upward to the root.

Acceptance criteria

• A container with a single child that uniquely provides language X: removing that child from the container's childIds results in the container's availableLanguages no longer including X.
• A container with two children, one providing language X uniquely and the other not: removing the child that does not provide X leaves the container's availableLanguages unchanged.
• The recompute triggered by removal cascades to the root, not just the immediate parent (a grandparent's availableLanguages also updates when appropriate).
• Adding a child to childIds in the same mutation continues to work as before (no regression on the already-correct add path).

Blocked by

• availableLanguages: cycle-safe, cascade-to-fixpoint recompute engine #9517 (needs the cascade engine to route the recompute through)

[tanflem]

🔒 Phoebe holds a lease on this issue — runtime 23d237d8-ffd4-4f4e-960e-7682f69cf890, branch phoebe/bot-0-issue-9518.

This lease is refreshed periodically while work is in progress. If the heartbeat goes stale (the runtime died) or this runtime restarts, Phoebe reclaims the issue back to the ready queue automatically — no manual relabel needed.

[tanflem]

Investigated this issue and found it's already fully addressed: PR #9516 (opened against the parent epic #9515, before sub-issues #9517-#9525 were split out) already implements the cascade engine (#9517's scope) and, on top of it, the exact fix this issue asks for — videoUpdate now calls recalculateAvailableLanguagesCascade when childIds changes, recomputing the container from current source data (own published variants ∪ live children's current values) and cascading upward, rather than trying to incrementally patch the old value through a relation that's already severed.

Verified against this issue's acceptance criteria, all covered by tests in that PR:

• Single child uniquely providing language X, removed → parent drops X: updateAvailableLanguages.spec.ts — "removal is symmetric with addition: dropping the only child that provided a language removes it from the parent"
• Two children, removing the one not providing X → unchanged: updateAvailableLanguages.spec.ts — "leaves a shared language in place when only one of two providing children is removed"
• Cascades to the root, not just the immediate parent: updateAvailableLanguages.spec.ts — "cascades a language change to a three-level-deep container hierarchy", plus the walker's explicit recursion (no longer stopping after one hop)
• Add path unaffected: video.spec.ts — "recomputes and cascades availableLanguages when childIds changes" / "does not recompute availableLanguages when childIds is not part of the update"

I added Closes #9518 (and a note) to PR #9516's description so this issue closes automatically when that PR merges. Opening a second, separate PR for just this piece would duplicate and directly conflict with #9516's changes to video.ts and updateAvailableLanguages.ts, so I'm not doing that. Releasing my claim on this issue — no further action needed here; tracking happens on #9516 / #9515 now.

[tanflem]

⚠️ Phoebe claimed this issue and released it with no PR (attempt 1/3, no-commit). It stays in the ready queue and will retry once the claim lease expires.

💤 Phoebe ran this issue and found nothing to do — no commits, no verification failures. It will not be re-selected until the issue body changes, or a human applies phoebe:retry.