Migrate linting/formatting to Biome + ESLint v9

[Vasco-jofra]

Summary

• Replace Trunk + Prettier with Biome (formatter) + ESLint v9 flat config + pre-commit hooks, matching the vscode-weaudit project setup
• Upgrade TypeScript from 4.9 to 5.9, ESLint from 8 to 9, typescript-eslint from 5 to 8
• Resolve all ESLint warnings (return type annotations, eslint-disable comments for intentional patterns, async/promise fixes) so the strict recommended-type-checked ruleset runs at error level with 0 violations
• Add CI workflow (lint_and_format.yml) for biome check, eslint, and tsc
• Add .git-blame-ignore-revs for the two formatting/annotation commits

Infrastructure changes

Removed	Added
.trunk/ (8 files)	.eslintrc.cjs (ESLint v9 flat config)
.github/workflows/lint.yml	.github/workflows/lint_and_format.yml
justfile	biome.json
prettier dep	.pre-commit-config.yaml
	.git-blame-ignore-revs

Code changes (no semantic changes)

• Added explicit return type annotations to ~170 functions/methods/callbacks
• Added eslint-disable comments for SARIF JSON parsing (no-unsafe-*) and naming patterns (naming-convention)
• Removed unnecessary async from functions that don't await
• Added void operator to fire-and-forget promises
• Fixed == to ===, added curly braces, etc.

Test plan

• npm run lint — 0 errors, 0 warnings
• npm run format:check — all files clean
• npm run typecheck — passes
• npm run compile — passes

🤖 Generated with Claude Code

In general, to fix missing origin verification for a postMessage handler, you must validate that the incoming message comes from an expected, trusted context before acting on it. This is usually done by checking event.origin against a whitelist of allowed origins and, where appropriate, also checking event.source or message shape (e.g., a type field) before processing event.data.

For this specific code in src/webviewSrc/main.ts, the best fix with minimal behavioral change is:

• Wrap the body of the "message" event listener in a guard that ensures the event is from an expected context.
• In a VS Code webview, event.origin has a fixed value (typically "vscode-webview://" + ...), but we should not hard-code a specific host/path if we’re not given it. Instead, we can:
  • Check that event.origin is strictly equal to window.origin. For content running inside a webview, legitimate messages from the extension are delivered with the same origin as the current document, while cross-origin frames would differ.
  • Optionally, also ensure event.source === window to restrict to same-window messages (this is conservative and safe given we have no other constraints).
• Only when the origin check passes do we cast event.data to ExtensionToWebviewMsgTypes and call handleWebviewMessage(message).

Concretely:

• In src/webviewSrc/main.ts, within init(), change the message event listener (lines 29–33) to:
  • Early-return if event.origin !== window.origin.
  • Optionally, also early-return if event.source !== window.
• No new imports are needed, as window and event.origin are standard browser/webview APIs.

[fcasal]

I noticed that the current pull request setup does not trigger warnings on vscode if, for example, you remove one of the function declaration having a return void : void. In the weaudit codebase, the setup gives a warning for it (Missing return type on function.eslint[@typescript-eslint/explicit-function-return-type](https://typescript-eslint.io/rules/explicit-function-return-type))