test(lint-framework): prove lint request coalescing and settle the ignore-suggestion e2e test

[rodbegbie]

Disclaimer: this patch and description were produced by a Claude Code
agent working interactively under @rodbegbie's direction, per the "Be Honest"
section of AGENT_POLICY.md. Every design decision was reviewed and approved
by a human.

Issues

Refs #3911.

Important

Stacked on #3912. This branch is based on that one, so the diff currently
shows its commit too. Only the top two commits belong to this PR:

• test(lint-framework): cover lint request coalescing with vitest
• test(chrome-ext): let linting settle before ignoring a suggestion

The vitest tests fail without #3912 — that is the point of them. Happy to
rebase once #3912 lands, or to squash the two together if you would rather.

Description

#3912 fixes the lint-scheduling race behind the flaky Can ignore suggestion
Firefox test but ships without automated proof, because
packages/lint-framework has no test harness at all
("test": "echo 'no tests'"). This adds one, and closes the remaining gap in
the e2e helper.

Vitest for lint-framework, following the harper.js and
obsidian-plugin precedent: browser mode via @vitest/browser-playwright,
headless chromium. Two tests drive a lint provider whose responses resolve on
demand, so a lint can be held in flight deliberately:

• requests dropped mid-flight produce exactly one follow-up lint, and it sees
  the final text
• a rejected provider does not leave the framework permanently wedged

Wired in as just test-lintframework plus a CI matrix entry. Without that the
package's tests would never run — lint-framework was not in just test.

A settle wait in testCanIgnoreSuggestion. It acted on the first highlight
to appear, which can belong to a lint computed against a prefix of the typed
text. That looks identical on screen but carries a different context hash, so
ignoring it records a hash matching nothing. #3912 narrows that window but does
not close it for this test; waiting for the follow-up pass does. Note the
ordering dependency: before #3912 a dropped request was never re-run, so no
amount of waiting converged.

Demo

N/A — test-only change.

How Has This Been Tested?

Both new tests were confirmed to fail against upstream/master and pass with
#3912 applied:

RED   expected [ 'T' ]      to deeply equal [ 'T', 'This is a mistaek.' ]
      expected [ 'First.' ] to deeply equal [ 'First.', 'Second.' ]
GREEN 2 passed

Worth recording, because it nearly went the other way: the first version of
these tests passed against unfixed code. LintFramework polls itself every
second to cover editors that fail to emit events, and the original waits span
roughly 1.6 seconds of animation frames — long enough for that poll to supply
the "follow-up" lint the test was checking for. Every wait is now bounded to
ten animation frames, comfortably below the poll, so a pass means the framework
re-linted deliberately rather than being rescued.

A third test ("does not re-lint when nothing arrived during the pass") was
written and then deleted. It failed even against unfixed code, because
attachWindowListeners subscribes to scroll, resize and selectionchange
and ambient events legitimately trigger re-lints. No production change makes it
fail cleanly, so it was noise rather than coverage.

Also run: just format and pnpm -w run check clean across 365 files;
just test-lintframework green end to end.

Noted but not fixed

update() calls requestLintUpdate() without awaiting or catching it, so a
rejected lint surfaces as an unhandled promise rejection rather than reaching a
caller — in real browsers, not only under test. #3912 releases the mutex but
does not stop the rejection escaping. It is suppressed narrowly in the one test
that provokes it rather than widening #3912's scope. Happy to file it
separately if useful.

AI Disclosure

• I am a human and didn't use any AI.
• I used LLM features of my editor, but not an agent.
• I used an AI agent interactively.
• I am an agent or I got an agent to do the work autonomously.

An agent wrote the patch and this description, interactively, with a human
approving the design, the scope and the final diff. Not autonomous.

If Your PR Implements or Enhances a Linter

N/A — this changes test infrastructure, not a linter rule.

Checklist

• I have performed a self-review of my own code
• I have added tests to cover my changes
• I have considered splitting this into smaller pull requests