refactor(frontend): drop synchronous setState-in-effect at four of #176's six sites

[tyler-rich]

Part 1 of #176. Refactors findings 1, 2, 3 and 5 so none of them calls setState
synchronously from an effect body, preserving behaviour at every site.
frontend/eslint.config.js is untouched — react-hooks/set-state-in-effect stays 'off',
override and comment exactly as they were. Findings 4 and 6 and the removal of the override are a
follow-up; #176 stays open.

What replaced each site

#	Site	Replacement
1	pages/LoginPage.tsx	The oidc_error message is seeded by a lazy useState initializer over a module-level oidcErrorCode() helper. The effect keeps only the history.replaceState that strips the parameter — the part that genuinely touches something outside React.
2	components/settings/OidcLinkCard.tsx	Same treatment for both oidc_link* banners, over a shared linkParams() helper. Both parameters are still honoured independently, including the unknown-code fallbacks.
3	pages/NewScanPage.tsx	The scanner clamp moves out of an effect into a chooseTargetType handler — the target-type control is the only thing that can invalidate the pairing, since the scanner picker only offers the current type's own scanners.
5	pages/ScanDetailPage.tsx	findingsLoading is derived from a settled-request key (findingsSettledKey !== findingsKey) instead of stored, and loadFindings settles in both post-await branches rather than a finally.

Two choices worth calling out:

• Finding 3 is deliberately not a derive-during-render. allowed.includes(scanner) ? scanner : allowed[0] would shadow the displaced choice rather than overwrite it, so leaving a target type and coming back would resurrect a scanner the user is no longer on. The clamp stays destructive, as it was, and a test pins that difference.
• Finding 5 fixes a real flash. The commit in which a scan became succeeded previously rendered an empty findings list with the loader already down — "No findings match the current filters" over a request that had not answered yet.

The one line touched inside finding 4

Removing findingsLoading leaves setFindingsLoading(false) in the per-:scanId reset effect
uncompilable. It becomes setFindingsSettledKey(null). The effect keeps its structure, comment and
intent; ScanDetailPage.scanIdReset.test.tsx is unedited and still passes. Nothing else in findings
4 or 6 was changed, and ScansPage.compare.test.tsx is untouched.

Tests

Four new test files, 16 new tests. Each contains one assertion verified to fail against the
pre-refactor version of its own file (reverted with git checkout HEAD --, re-run, restored):

Site	Test file	Biting assertion	Pre-refactor result
1	LoginPage.oidcError.test.tsx	banner present in the first commit	expected false to be true
2	OidcLinkCard.callback.test.tsx	exactly 1 commit before the status fetch lands	expected 2 to be 1
3	NewScanPage.scannerClamp.test.tsx	no commit has zero scanner options selected	[1,1,…] to not include +0
5	ScanDetailPage.findingsSpinner.test.tsx	no commit says "no findings match" while the first request is in flight	[Array(11)] to not include true

Since these are behaviour-preserving refactors, the biting assertion is necessarily about which
commit the correct value lands in — which is what the rule is about — while the surrounding
assertions pin the behaviour and pass against both versions. Per-commit observation uses
<Profiler onRender>; Testing Library's render flushes passive effects inside act, so a plain
post-render assertion cannot see the intermediate state at all.

Measurement with the rule temporarily enabled

18 findings before (matching #176's 6/12 split exactly), 15 after — not 14. Sites 1, 2 and 3 are
gone outright; ScanDetailPage's void loadFindings() still reports.

The genuine defect #176 named for finding 5 — a synchronous setFindingsLoading(true) before the
first await — is gone. What remains is the analyser artifact the issue documents for the other 12:
probing the installed 7.1.1 shows void load() reports even when load's only setState follows an
await and there is no try/catch, and that adding a try/catch reports even when the catch
calls no setState at all. The only shapes that go silent are ones where the compiler bails on the
function. So finding 5's line has migrated into the out-of-scope fetch-on-mount population.

A consequence for the follow-up, recorded in the archive: #176 pairs "remove the override" with
"npm run lint is clean", and those cannot both hold while the 12 fetch-on-mount findings report at
error and are out of scope. That needs a decision the issue does not yet contain.

Verification

npm run lint clean · npm run format:check clean · tsc -b clean · npm run build clean ·
npm test 26 files / 96 tests passing (was 22/80 at #178).

See docs/ARCHIVE.md § Deviations for the full account;
docs/upgrades/frontend-toolchain-86.md Step 3 now records that its held-back rule closes out in
two parts.