[CatarinaGamboa]

Description

Closes #155.

The State Machine view now lists the displayed machine's state refinement errors beside the diagram. Previously they appeared only after clicking "View error on state machine" in the Verification view.

• Matching. Errors are matched to the machine by class name, across files. The error is usually reported in the caller's file, while the machine comes from the refinements file. The check is a single predicate, so a state-group check can be added for multiple @StateSet support.
• Items. Each item shows the call (root.getFirstChild()), receiver, Found, Required and a source link. These use the new liquidjava-fsm 0.1.4 error context and fall back to the diagnostic's expected/found text when it is absent.
• Selection. Selecting an item uses the same path as "View error on state machine", which now preselects its error. Clicking the selected item or "Show general diagram" clears the selection.
• Re-verification.
  • Fixed errors are removed.
  • The selection is kept only if that error still exists. A moved error is followed only when its call had exactly one error before and after verification.
  • The diagram is rebuilt from the latest machine.
  • The view re-renders only when the list or the diagram changed, and keyboard focus returns to the same item.
• Layout and accessibility. The list sits beside the diagram when wide and below it when narrow. Items are buttons with aria-pressed, and the selected item also changes its icon. With no state errors, the view is unchanged.
• Escaping. renderLocationLink now escapes data-file.
• Dependency. Bumps liquidjava-fsm to 0.1.4.

Tests

Run against liquidjava-fsm 0.1.4 and verifier 0.0.35 from Maven Central:

• npm run lint and npm run test:typecheck: clean.
• npm run test:unit: 56 passed in 6 files. The 20 new tests are in state-errors.spec.ts and script.spec.ts.
• npm test (VS Code): 9 + 1 passing, including the new state-errors integration test.
• Server mvn test: 24 passing.
• Local smoke test: passed.

A new integration test checks that the webview receives the caller-file state error together with the machine of the refinements file. It uses the new TreeNodeRefinements and FailingTreeNodeState fixtures.

Also checked in headless VS Code with two DefaultMutableTreeNode errors, using the real verifier output: both are listed with their receiver, Found and Required, and selecting and clearing works.

Independently reviewed; all findings were fixed with regression tests.

Open questions

• Clicking an error's source link opens the caller file, and the view then shows "No state machine available". Should it keep the selected error's machine?
• When nothing is known about the receiver, Found reads true. Should it read something like "no state known for root"?
• Several required states are joined with ||. Should they be joined with "or" instead?

#117 touches the same webview files; whichever PR merges second will be rebased.

🤖 Generated with Claude Code