docs(changelog): file the typed legacy-provider-id rejection as a breaking change

[code-yeongyu]

Pre-release changelog correction, found while preparing the senpi release for #1989.

The problem

The subscription provider rename landed eight [Unreleased] entries in packages/coding-agent/CHANGELOG.md. All eight sat under ### Changed, and ### Breaking Changes was empty.

Seven of them belong under Changed — they describe migrations and normalizations that preserve behaviour for an existing user (auth.json, settings.json, the accounts directory, models.json, session restore, the display rename, the internal rename).

One does not. A typed legacy provider id now hard-errors:

Typing a renamed provider id now tells you the new one: /login openai-codex and --provider claude-sdk-oauth fail with the new id named…

That is the deliberate counterpart to normalizing ids read from disk — config written by an older version is migrated and never rejected, while an id the user types is rejected by name. It is also the single change in this release that can break a user's script, alias or CI invocation. Filed under "Changed", a user scanning the release notes for what breaks would never see the one thing that breaks.

The change

Moves that one entry to ### Breaking Changes. The text is unchanged; only its section moves. The other seven stay where they are.

1 file changed, 2 insertions(+), 1 deletion(-)

Doing this before the release is cut, rather than after: release notes are generated from these sections, so a mis-sectioned entry ships as a misleading release note and cannot be corrected in place once published.

Part of #1989

---

Summary by cubic

Moves the changelog entry for typed legacy provider ids being rejected to the Breaking Changes section, so release notes flag it as the one change in this release that can break user scripts, aliases, or CI invocations. The text is unchanged; only its section moves. Part of #1989.

^{Written for commit 692ffe9. Summary will update on new commits.}

[code-yeongyu]

CI note: Test (coding-agent 2/3) red, unrelated to this diff

The failing test, by reason rather than check name:

FAIL test/suite/regressions/issue-1961-public-endpoint-absent.test.ts
  > issue 1961: a generation that lost its public entry
  > notices the loss, so it can drain instead of living on unreachable
AssertionError: expected +0 to be 1

Why it cannot be this PR. The diff is one file, packages/coding-agent/CHANGELOG.md, +2/−1 — a markdown section move, text unchanged. The failing assertion covers RPC host generation socket bookkeeping. There is no mechanism by which relocating a changelog bullet changes daemon endpoint state.

Local evidence. That exact test, run on a tree containing main plus the merged rename work, with SENPI_RPC_HOST_* scrubbed from the environment:

run 1: Test Files 1 passed (1) | Tests 1 passed (1)
run 2: Test Files 1 passed (1) | Tests 1 passed (1)

2/2 green. The test is recent (61075f5685, the RED contract for #1961) and asserts liveness of a generation whose public entry was removed — timing-sensitive under a loaded runner.

Merging on the green local gate per the standing order, with the CI reason recorded here rather than merged over silently.

(Aside for anyone reading job logs: gh api .../jobs/<id>/logs prints nothing and looks like a retention/permission problem — it is actually refusing on terminal escape sequences. gh api --allow-escape-sequences returns the body.)

[code-yeongyu]

Step-level read (per the standing diagnostic rule):

• Test (coding-agent 2/3) failed at step 8 "Test shard" — the issue-1961 RPC-generation liveness assertion above.
• Check and test failed at step "Verify all gates": gate results: success failure success success success success success / - test-coding-agent: failure. It is a rollup of that same shard, not an independent failure.

So this is one red, not two. It is also not a bundle-freshness red: this PR touches no packages/senpi-task, no packages/isolation-core and no version string — the diff is one markdown file, +2/−1. Freshness gates fail at a "Verify committed … bundle is current" step; this failed at a test-shard step.

Merging on the green local gate (2/2 on that exact test) with the CI reason recorded above.