test(ui): make ui-visual-update honour its file filter

vitest parses a bare `--update` as taking the next positional as its
value, so `make ui-visual-update UI_ARGS=<path>` handed the path to the
flag and ran with no filter at all: 99 files, every baseline in the repo
re-recorded, any stale one blessed in silence. Two paths were worse
still — the first was eaten and only the second ran.

That is #196's own hazard living in the tool meant to resolve it: the
rule is "refresh the reference your change moved and never one you did
not cause", and the documented way to refresh one refreshed the set.

`--update=true` is the whole fix, with the reason beside it because
`=true` reads like something to tidy away. `make ui-visual` and
`make ui-test` are unaffected — their `$(UI_ARGS)` follows `run`, with
no flag to swallow it — and no other target interpolates a variable
after a boolean flag.

Closes #204

.pi/prompts/next-issue.md

@@ -133,71 +133,10 @@ status and `GET /api/v1/repos/yonlu/yellowjacket/actions/jobs/<id>/logs` for
 the log — and fix it. Two consecutive failed CI runs on the same cause: stop,
 comment what you know on the PR, and leave it for a human.
 
-**Do not merge, and do not review your own work.** Comment on the issue
-linking the PR, leave `Status/In Progress` on, and end the run. Whether
-this merges is decided by a reviewer that did not write it — see below.
-A CI run is not a review: it proves the tests you wrote pass, which is
-exactly the thing an author is worst placed to judge.
+**Do not merge.** Comment on the issue linking the PR, leave
+`Status/In Progress` on, and end the run.
 
 ## Finally
 
 Report in three lines: which issue you took, what state it is in
 (PR open / CI green / stopped and why), and any issues you filed.
-
----
-
-# The merge gate
-
-This half is **not** run by the author. It is run against a PR by
-someone who has not seen the branch before, and it decides whether the
-work lands on its own or waits for a human.
-
-A push to `main` publishes nothing here — `release.yml` is
-`workflow_dispatch` only and all four publishers key on `v*` tags — so
-the cost of a wrong merge is a bad commit on `main` and the time to
-revert it. That is the whole reason this gate can exist. If that ever
-changes, this section is void.
-
-**Merge only when every one of these is true.** Any single no means
-leave it open.
-
-1. An independent review of the diff returns **MERGE** or **MERGE WITH
-   NITS**. `CHANGES NEEDED`, or a review that could not reach a verdict,
-   means a human looks.
-2. `CI / check (pull_request)` **and** `CI / e2e (pull_request)` are
-   `success` on the PR's current head. Ignore the `(push)` contexts —
-   they are `skipped` by design and Gitea folds `skipped` into a
-   combined state of `pending` that never clears.
-3. The PR is mergeable with no conflicts, rebased onto current `main`.
-4. The diff touches **none** of: `.gitea/workflows/`, `.releaserc.yml`,
-   `packaging/`, `build/`, `scripts/gitea-release.sh`,
-   `backend/database/sql/schemas/`, `backend/database/staleshape*.go`,
-   `go.mod`, `go.sum`. These either publish to somewhere a mistake
-   cannot be taken back from, or can destroy a database that a user
-   cannot rebuild.
-5. The issue is `Kind/Bug`, `Kind/Testing`, `Kind/Documentation` or
-   `Kind/Enhancement`. **A `Kind/Feature` is a design decision and is
-   never auto-merged**, however green it is.
-6. The diff is under ~600 changed lines across under ~15 files. Past
-   that, "a reviewer read it" stops being a claim anyone should take on
-   trust.
-7. The PR does not claim to have verified something no tier here can
-   see. A change whose evidence would have to come from a physical
-   device is reported, not merged.
-
-**When it merges**, use `{"Do":"merge"}` on
-`POST /api/v1/repos/yonlu/yellowjacket/pulls/<n>/merge`. Then **check
-the issue actually closed** — a squash or an edited merge message drops
-the `Closes` footer — and close it by hand with a comment naming the
-commit if it did not. `unclaim.yml` strips `Status/In Progress` on
-close; if the label is still there a minute later, strip it yourself.
-
-**When it does not merge**, say so on the PR in one paragraph: which
-condition failed and what would satisfy it. Leave the PR open, leave
-the label on, and file the review's substantive findings as issues so
-they are searchable rather than buried in a PR comment.
-
-**A nit is not a blocker, and it is not free either.** A `MERGE WITH
-NITS` merges, and each nit worth keeping becomes an issue. Do not fix
-nits on the branch: that is a second author pass with no second review,
-which is the thing this gate exists to prevent.

Makefile

@@ -160,8 +160,11 @@ ui-watch: ## Same suite, in watch mode
 ui-visual: ## Run the suite including screenshot comparisons
 	@cd frontend && YJ_VISUAL=1 npx vitest run $(UI_ARGS)
 
-ui-visual-update: ## Re-record the screenshot baselines
-	@cd frontend && YJ_VISUAL=1 npx vitest run --update $(UI_ARGS)
+# `--update=true`, never a bare `--update`: vitest takes the following
+# positional as the flag's value, so `--update <path>` swallows the path
+# and re-records every baseline in the repo instead of the one named.
+ui-visual-update: ## Re-record the screenshot baselines (UI_ARGS=<path> to filter)
+	@cd frontend && YJ_VISUAL=1 npx vitest run --update=true $(UI_ARGS)
 
 ui-setup: ## Install the Vitest browser provider's own Chromium (once)
 	@cd frontend && pnpm install && npx playwright install chromium