[k0d3r1s]

The banner's Dismiss button hides a finding but does not settle it, so the agent receives the same finding again in a later turn.

dismissAdvice only sets delivered_at on the row it shows. The chain root keeps resolved_at = NULL, so:

1. readOpenFindings still lists the chain in the next reviewer prompt under "Findings you raised earlier on this thread that are still open".
2. The reviewer re-checks it, finds it unchanged (the user chose not to act on it), and raises the same key again.
3. The re-raise joins the chain through repeat_of, is pending, and reaches the agent through the turn briefing or the advisor_review tool result, often with "The agent was told this before and did not resolve it."

The panel's resolveFinding already settles a chain correctly, and readOpenFindings, readPendingAdvice and the tool result all honour that through chainIsResolved. Only the banner path is missing it.

This change:

• Makes dismissAdvice settle the chain root the way resolveFinding does (resolved_at set, empty resolved_reason and decision, so the panel shows "You dismissed it") and marks the chain's pending rows delivered. It collects those rows before settling the root, because readPendingAdvice skips settled chains.
• Records the dismissed severity in a new dismissed_severity column on the root, appended as the last migration. If the advisor later raises the same finding at a higher severity than the user dismissed, the chain reopens, so dismissing a nit cannot silence a later blocker. The same or a lower severity leaves it settled.
• Clears dismissed_severity in both resolveFinding updates, so a chain settled from the panel keeps today's behaviour and never reopens.

The RPC schemas do not change. The stale-adviceId guard is unchanged.

Validation:

• Five new tests in server.test.ts: a same-severity re-raise after dismiss stays out of pendingAdvice, the turn briefing and the reviewer's open list; the tool returns "Advisor pass: no unresolved findings."; a higher-severity re-raise reopens the chain; the panel shows the chain resolved with an empty decision; a panel-resolved chain does not reopen on escalation. The first four fail without the server.ts change.
• npm run verify (typecheck, 137 tests, build) passes on Node 22.19.0. The generated bundle is updated.
• Migration compatibility: I checked the new statement list against a copy of a real 0.1.4/0.1.5 database with the SDK's index-and-hash rule. The 30 recorded migrations match and only dismissed_severity is added.
• I run this build (with only a version bump on top) on BB 0.47.1 against that database. It starts cleanly, keeps the existing review history, and applies the new migration.

Not tested: a scripted end-to-end run of the banner in the app. The behaviour is covered through the RPCs the banner calls.

[salemsayed]

Thanks for this fix and the careful write-up. I couldn't push a follow-up to your branch, because maintainers can't edit forks owned by an organization. So I've opened #16 with your commit as you wrote it, plus one commit on top. When I tested it in a real BB, rounds raised while a finding was dismissed all reached the agent together once an escalation reopened it, and the banner said the agent had been told before when it hadn't. Closing this in favour of #16.