fix(close): take the review follow-ups on changed transactions

[jfrench9]

Summary

Takes the follow-ups from the automatic review of #444, which merged before they were applied. No new surface: these tighten the Changed transactions panel in the Closing Book.

Changes

Ledger → Closing Book → Changed transactions

• Refusals now go through friendlyError, as this repository's guidance asks of a write surface. The panel showed the API's detail text and decided two outcomes by matching that text itself. Those two (a change already settled, and a change flagged again while it was open) are now classes in src/lib/ledger/errors.ts, with a code the panel reads.
• A change that was settled elsewhere before it could be reviewed now drops off the list, as one settled mid-review already did.
• When the list is cut off at 200, it is fetched again after each change is settled, so the ones it hid come into view. The note under the list said "settle these to see the rest" while nothing refetched; it now reads "Showing 200. More appear as these are settled."
• Opening a change clears the previous outcome banner, so "Restated…" no longer sits above a different change. A graph switch clears the note, notice and errors as well as the list.
• The reference links to the source only when it is a web address.

Closing Book sidebar

• The Changed transactions entry is added to whichever category holds the reconciliations worklist, found by item type instead of by the label "Reconciliations".

Period close hub

• The blocker's "N holding this close" is left out when the calendar reports none; the link stays.

One suggestion not taken: preselecting another treatment when the recommended one is unavailable. The only one left can be "Mark as handled", and that should be chosen, not defaulted.

Deploy Notes

None

Testing

• npm run test:all stages ran through the pre-commit gate: 100 files, 792 tests passed; format, lint, typecheck and cf-lint clean. Nine tests are new: the two refusal classes and an uncoded refusal in errors.test.ts, and in the panel a change settled before review, the outcome clearing, the refetch after a settle on a full page (and no refetch otherwise), and the web-address check. The page test now uses a renamed category, and the hub test covers a zero count.
• npm run build not rerun; no route, layout or client boundary changes since feat(close): settle changed transactions in the Closing Book #444's build.
• Not rechecked in a browser.

🤖 Generated with Claude Code

[github-actions]

Change classification: normal — platform or application code changed.

A normal change carries a documented automated review on this pull request before merge, in place of a second human approver. The change-classification job requests that review and passes once it has been posted. Recorded by the change-classification job.

[jfrench9]

@claude please review this PR

[claude]

Claude finished @jfrench9's task in 21s —— View job

---

Review of PR #445

The PR looks sound and I'd merge it. The follow-ups from #444 are implemented as described. I read the diff and checked a few claims against the repo. I did not run the test suite or the build.

Checked and fine

• friendlyError gains two coded classes, change_already_settled and change_flagged_again, and the panel acts on code instead of matching detail text. The new tests cover both classes and the uncoded case.
• loadList has a listSeq guard. It replaces the old cancelled flag, and the guard also drops a stale refetch after a graph switch. A failed refresh keeps the rows already on screen.
• webHref only allows http(s)://, which rules out javascript: URLs.
• The sidebar match on itemType === 'reconciliations' uses the same discriminator as StructureSidebar.tsx:79.
• Setting the already-settled outcome in dropRow and clearing it in openItem behaves as the description says.
• The hub's zero-count guard is fine.

Minor points (non-blocking)

1. Stale notice after a re-flagged change settles elsewhere. In handleSettle, the change_flagged_again branch runs await openItem(selectedId) and then setNotice(...). If that re-preview returns change_already_settled, openItem calls dropRow, which closes the item. The code then sets the notice anyway, so a "latest figures" notice is left with no item open. openItem swallows its own errors, so the same thing happens if the re-preview fails for any other reason. It is cosmetic: the next openItem clears the notice. A simple fix is to set the notice only when selectedId is still open, or to have openItem return a boolean.
2. Duplicate webHref call. ChangedTransactionsPanel.tsx calls webHref(item.externalUrl) twice in the same JSX expression. Computing it once per row would be a small tidy-up.
3. Refetch overwrites the optimistic removal. After a settle on a full page, loadList() replaces items with the server's list. That is intended. If the backend list is briefly stale, though, a just-settled row could reappear. This is unlikely, and the PR description doesn't claim to handle it.
4. Substring match on re-flagged with a newer payload. The matching now depends on exact API wording, where the old code matched only re-flagged. The new test pins the current message. Keep it in sync if the backend text changes.

Not rechecked in a browser, as the PR notes.