feat(nc-review): mention the author, and track what a re-review fixed

[will-lamerton]

Two changes.

1. Mention the PR author

So the review reaches them rather than waiting to be noticed.

Bots are skipped. dependabot and github-actions cannot read a review, and an @-mention on every dependency bump is pure noise. Detection uses the API's is_bot flag rather than matching a [bot] suffix, which would miss accounts that do not follow the convention.

2. Track what a /re-review actually fixed

Previously a re-review re-derived every finding from scratch, with no memory of what it had already said. That means re-filing points the author has already fixed — which is worse than not re-reviewing at all, because it tells someone their work did not land.

The most recent nc-review comment is now included in the context, with instructions to sort each prior point into resolved / not resolved / cannot tell, plus a new addressed array in the schema.

Fixed points render explicitly rather than being silently dropped — absence is ambiguous, and from the author's side reads as the bot forgetting rather than the work landing:

nc-review: comments — 1 important

@awhite0030 — a few things worth a look, none blocking.

The dispatcher gap is fixed. One test concern remains.

Addressed since the last review

• ✅ The dispatcher now has a skill branch, so subscriptions no longer fall through silently.
• ✅ fix.patch and the two .orig files are gone from the diff.
• ✅ A changeset was added.

🟠 important · tests · source/skills/registrar.spec.ts

Still no end-to-end test that a skill: subscription reaches the dispatcher.

The rubric also now says plainly that re-raising a fixed point is the fastest way to make people stop reading, and that a fix can introduce a new problem which is a new finding like any other.

Verified

Extracted the real Post review step and ran it against three cases:

• re-review with three addressed items and one remaining finding → renders as above
• bot author → no mention emitted
• first review with no addressed field → no empty block

[github-actions]

No changeset found

This PR does not add a changeset, so it will not appear in the changelog or trigger a release.

If the change is user-facing, add one:

pnpm changeset

Pick a bump (patch / minor / major) and write the changelog entry in our usual voice ("Added X... Thanks to @you. Closes #123."), then commit the generated .changeset/*.md file.

If this PR is docs-only or a chore that needs no release note, you can ignore this — or run pnpm changeset --empty to record that intentionally.

[github-actions]

nc-review: nothing to raise

The change adds an author mention to nc-review comments (skipping bots via the API's is_bot flag) and forwards the most recent nc-review comment to the model on a re-review, paired with a new addressed field in the verdict schema. The shell, jq, and Markdown pieces hang together: the filter select(.body | startswith("### nc-review")) matches the headings the bot itself writes, last // empty picks the right one, and the empty-file fallback (2>/dev/null || : > ... plus [ -s ... ]) keeps HAS_PREV honest when the API fails. The author-mention block defaults to skipping on error (IS_BOT=true fallback), which is the safe direction. No security regressions: the previous-review body is filtered to github-actions[bot] only, so it carries no attacker-controlled content into the prompt. Two minor inefficiencies are not worth raising — a second gh pr view for the author rather than reusing /tmp/nc-review/pr.json, and a re-review of a prior clean verdict starts fresh without an explicit note. Ready to merge.

---

_{🔴 blocking · 🟠 a reviewer would ask for a change · ⚪ optional}

_{Automated code review — correctness, security, design, tests, plus duplicates and scope. A human still decides; this is not a substitute for review and is not exhaustive. The required status checks separately cover lint, formatting, types, unused dependencies, the test suite and the build. This bot never merges. Maintainers can rerun with /re-review.}