Retire the overlap-release acceptsLyrics field once no supported peer reads it

[atomantic]

Problem

#4826 moved the "does this build carry lyrics on the wire" probe from the per-capability capability.acceptsLyrics boolean to a status-root features: string[] list. The old field is still emitted, deliberately, so a consumer running the pre-#4826 build keeps working through the overlap release.

Once no supported peer reads the legacy field, it should go. Leaving it indefinitely re-establishes the two-spellings problem #4826 removed: a future reader sees a capability field that looks live but is only a compatibility shim.

What to do

Remove the field and its fallback. Every read already funnels through one helper on each side, so this is a small, contained deletion:

• server/lib/federatedMediaWire.js — drop acceptsLyrics from federatedMediaCapabilitySchema, and drop the lyrics entry from FEDERATED_MEDIA_LEGACY_FEATURE_TELL
• server/services/federatedMediaProvider.js — stop emitting acceptsLyrics at both capability sites (configuredAudioCapabilities, localGeneratorCapabilities)
• client/src/lib/federatedMediaReadiness.js — drop the lyrics entry from LEGACY_FEATURE_TELL
• docs/FEDERATED_MEDIA_PROVIDERS.md — drop the acceptsLyrics row from the lyrics signal table and the retirement note in the features section
• Tests: server/lib/federatedMediaWire.test.js, server/routes/music.test.js, server/services/federatedMediaProvider.test.js, client/src/lib/federatedMediaReadiness.test.js, client/src/components/music/MusicGenPanel.test.jsx all carry legacy-path cases that go with it. Keep every features-path case.

The inputAssets legacy tell (capability block presence) stays — it is not a shim, it is the only signal a mid-overlap peer sends, and it is genuinely per-model besides.

Blocked until

The release carrying #4826 has shipped and installs have had a reasonable window to update. Verify no supported peer still depends on the field before removing it — a consumer that has not updated will silently degrade every remote lyrical render to instrumental, which is exactly the failure the field was added to prevent.

Refs #4826

[atomantic]

Claimed this, verified the blocked-until gate, and am parking it: the overlap release is ~2 hours old.

Evidence

• Replace the per-capability acceptsLyrics flag with a status-root features list #4826 merged via PR Replace the per-capability acceptsLyrics flag with a status-root features list #4855 (9aa7c6e), and git tag --contains 9aa7c6e → v2.48.0.
• v2.48.0 published 2026-08-23T12:17:07Z; checked at 2026-08-23T14:26Z.

That is the release carrying the shim, so "the release carrying #4826 has shipped" is satisfied — but "installs have had a reasonable window to update" is not, by roughly the width of a lunch break. Every install still on v2.47.0 is mid-overlap right now.

Why shipping it today is the exact failure the field prevents. Both directions break, not just one:

• Removing the emitter (federatedMediaProvider.js) — a v2.47.0 consumer reading a post-removal provider sees no acceptsLyrics and cannot read features (it predates Replace the per-capability acceptsLyrics flag with a status-root features list #4826), so it degrades every remote lyrical render to instrumental.
• Removing the reader fallback (FEDERATED_MEDIA_LEGACY_FEATURE_TELL.lyrics and its client mirror) — a post-removal consumer reading a v2.47.0 provider sees acceptsLyrics, ignores it, finds no features list, and degrades identically.

Silent instrumental fallback across other people's installs is not something this run can verify away, and it is not reversible from here once merged — cross-install compatibility is first-class per AGENTS.md.

No partial slice is worth shipping. The deletion is atomic; carving it produces a half-retired field, which is strictly worse than either end state.

Labeling blocked rather than needs-input — nothing here needs a decision, only elapsed adoption time. Per the filing conventions, blocked is the label for a genuine dependency/precondition, and the autonomous claim queue skips it either way.

What unblocks it: at least one more release cycle past v2.48.0 (so v2.48.0 is no longer the newest thing anyone could be a version behind), plus a check that no supported peer still reads the legacy field. The deletion list in the body is accurate and still applies as written — I re-grepped it and every named site is present and unchanged. Drop blocked and it is ready to claim cold.