build: keep the static gates out of Flutter build output

[winetree94]

Problem

dart run melos verify:debug leaves apps/coder_app/build/ populated. Running dart run melos verify afterwards then fails — not on our code, but on a third-party source the Flutter build just wrote:

apps/coder_app/build/linux/x64/debug/plugins/super_native_extensions/
  cargokit_build/tool/bin/build_tool_runner.dart

AGENTS.md:56-58 tells contributors to run both commands, so the documented workflow reliably breaks itself. I hit this twice on #79 and cleared it with rm -rf each time.

Three scanners, three mechanisms

I originally expected two offenders; running the real sequence surfaced a third (dependencies). Each gets the mechanism it actually has:

Gate	Symptom	Fix
analysis	discarded_futures error in the plugin source	analyzer: exclude:
format	reformats the plugin source	explicit file list from git
dependencies	build_tool reported as an undeclared dev_dependency	exclude: in the existing per-package config

The analyzer exclude lists both build/** and **/build/**, because apps/coder_app/analysis_options.yaml is a one-line include: of the root file and an exclude glob may resolve against either that package or the workspace root.

The formatter has no exclude flag, so tool/format_sources.dart hands it paths from:

git ls-files --cached --others --exclude-standard -- '*.dart'

Tracked plus untracked-not-ignored, so a brand-new file a contributor just wrote is still checked while ignored build output is not. This keeps .gitignore as the single source of truth rather than duplicating the ignore rules in code. Logic lives in lib/src/source_inventory.dart (pure, unit-tested) with a thin tool/ entrypoint, matching the existing verify_workspace.dart → verification_runner.dart split.

Verification

The acceptance test is the sequence that used to fail, run for real:

1. dart run melos verify:debug → exit 0, leaves build_tool_runner.dart on disk
2. dart run melos verify immediately after, no rm -rf → all 12 steps PASS

I also confirmed the old config genuinely fails on that file (1 analyzer diagnostic, 1 reformat) by stashing the change and re-running, so the fix is verified against a reproduced failure rather than assumed.

Formatter regressions checked: a mis-formatted tracked file exits 1; a brand-new untracked file is caught; offending files in different batches are all reported (batching does not stop at the first failure, matching dart format .).

Notes

• CI cannot regress on this. The Static checks job is a fresh checkout that never builds, and the Debug E2E jobs never run verify afterwards — which is also why CI never caught it.
• No melos clean script: it would not fix anything, since the tools would still scan whatever build output exists.