feat(lint): self-documenting diagnostics — suppression-comment hover, clickable rule docs, diagnostic tags

[fi3ework]

Summary

Make Rslint diagnostics self-documenting in the editor. Three capabilities, ordered by how much of the work lives in this repo:

1. Suppression-comment hover — hovering a rule id inside // rslint-disable-next-line no-floating-promises shows that rule's documentation (description + link to rstack.rs). This answers "why is this line suppressed?" directly at the comment. Neither the ESLint nor the Biome extension offers this; Ruff proves the pattern (ruff server answers textDocument/hover over noqa codes).
2. Clickable rule ids in the Problems panel — populate Diagnostic.codeDescription.href (LSP 3.16) from the rule's docs URL, so the rule id in the Problems panel links straight to the rule's page. dbaeumer.vscode-eslint does exactly this from meta.docs.url.
3. Diagnostic tags for dead code — emit DiagnosticTag.Unnecessary for unused-variable style rules (rendered faded) and DiagnosticTag.Deprecated for deprecated-API rules (rendered struck-through), so squiggles stay reserved for real errors. Also proven by vscode-eslint.

Where the work lives

Piece	Repo	Effort
Hover over disable-comment rule ids (languages.registerHoverProvider, derive docs URL from rule id)	this repo, client-side	2–3 days
codeDescription.href + DiagnosticTag on published diagnostics	Rslint upstream (Go LSP)	~1 day

The client-side hover can ship independently of the upstream half.

Constraints

• stacks/lint is a deliberate near-verbatim copy of the upstream extension with exactly seven documented adaptations (packages/vscode/AGENTS.md). A client-side hover provider is new behavior, not a divergence inside the copied files — implement it as a separate module registered by the stack, and if it must touch copied files, record it as an eighth adaptation in AGENTS.md.
• Docs URL derivation should not hardcode a URL scheme per rule; derive from one base URL + rule id, and degrade gracefully (no hover entry) for rules without docs.
• The upstream half needs an issue/PR on web-infra-dev/rslint; link it here once filed.

References

• Ruff hover over suppression codes: https://docs.astral.sh/ruff/editors/features/
• vscode-eslint codeDescription / DiagnosticTag usage: https://github.com/microsoft/vscode-eslint
• LSP codeDescription: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnostic

[fi3ework]

Design settled after reviewing the extension architecture and the rslint source at web-infra-dev/rslint@b0fd156. Decisions below; recorded in-repo as ADR 0004 (no bundled rule knowledge) plus two glossary terms (Inline directive, Rule docs link).

Shipping in this repo

1. Inline-directive hover — a new client-side module registered by the lint stack (separate module, not a divergence inside the copied files, so no eighth adaptation). Recognizes all four directives (rslint-disable, -enable, -disable-line, -disable-next-line), the equivalent eslint- prefix, // and /* */ comments, comma-separated rule ids, and the -- description trailer. The hover range is the individual rule id token; the directive keyword and bare (wildcard) directives show nothing. Content: rule id + docs link — no prose description (the server has none to give, see below). If a future rslint server advertises hoverProvider, the client-side provider yields — same rule the fmt stack already follows: never fight a server-registered capability.
2. DocumentLink on rule ids — same parser; rule ids render as ctrl+clickable links to their docs page, which also makes the hover discoverable.
3. Clickable rule ids in the Problems panel, client-synthesized for now — the lint middleware already intercepts published diagnostics; it parses the [rule-id] prefix the Go server puts on every message, sets Diagnostic.code + codeDescription.href, and strips the prefix from the message (the vscode-eslint shape). Guarded: a message that doesn't match passes through untouched, so an upstream format change degrades to the status quo instead of breaking. Explicitly transitional — deleted once upstream publishes the fields natively.

Principles (ADR 0004)

• No bundled rule knowledge. The extension hardcodes no rule list, no descriptions, no per-rule URLs. Everything is derived from the rule id by one formula — https://rslint.rs/rules/<plugin prefix minus '@', or 'eslint' for core rules>/<rule-name>, matching upstream's getRuleDocUrl — or parsed from server output.
• No network. Links are best-effort: a mistyped or brand-new rule id yields a dead link, never a validation round-trip. Consequently a typo in a directive stays silent client-side — the surviving squiggle it failed to suppress is the signal; proper reporting is upstream work (below).
• No configuration toggle for any of this.

Waiting on upstream (issue to be filed on web-infra-dev/rslint and linked here)

Verified against current rslint source: the LSP publishes only range/severity/source/message (internal/lsp/service.go, convertRuleDiagnosticToLSP), advertises no hover, and has no rule-metadata surface, so all of the following are upstream work:

• Native Diagnostic.code + codeDescription.href (retires the client-side synthesis in item 3)
• DiagnosticTag.Unnecessary / .Deprecated — only rules know their own nature; a client-side rule classification table is exactly the bundled knowledge ADR 0004 forbids, so capability 3 of this issue ships entirely with upstream
• Unused/mistyped-directive reporting (reportUnusedDisableDirectives is currently a documented divergence in rslint)
• Rule metadata (description) exposure, so the hover can grow a one-line description