id(repo): ~509 KB of raw clippy/cargo scratch output is tracked at the pkgs/id root — clippy_out4.txt, clippy_out5.txt and cargo-build-output.txt are unreferenced, and nothing stops the next dump #3097

Problem

Three raw tool-output scratch files are tracked at the root of pkgs/id — about 509 KB of clippy/cargo output that no build, test, doc, or script reads:

• pkgs/id/clippy_out4.txt — 274,569 bytes. First lines: Checking id v0.1.0 (/app/pkgs/id) followed by clippy warning: empty line after doc comment output for src/commands/find.rs:212.
• pkgs/id/clippy_out5.txt — 228,300 bytes. Same shape: Checking id v0.1.0 (/app/pkgs/id), then clippy diagnostics.
• pkgs/id/cargo-build-output.txt — 6,264 bytes. A cargo tree -i iroh dump (iroh v0.95.1, distributed-topic-tracker v0.2.5, id v0.1.0 (/home/user/code/pkgs/id)).

Evidence (verified this run, main 68d59a37)

• git ls-files lists all three as tracked files on current main.
• clippy_out4.txt and clippy_out5.txt were both added by commit 1646db17 ("style(id): resolve clippy-lint check failures in CI", 2026-10-30) — the lint output was committed alongside the lint fixes it described. cargo-build-output.txt was last touched by 1a291185 ("amd 414").
• A repo-wide search for clippy_out / cargo-build-output across *.nix, *.toml, *.md, justfile, and *.json finds no reference: nothing consumes these files. (Contrast the legitimate tracked text files in the same package — benches/baseline.txt, proptest-regressions/*.txt, tests/regressions/*.txt — which are read by benches/tests and are NOT part of this issue.)
• pkgs/id/.gitignore covers only .iroh*, test.*, .identity.db, .identity.redb — no pattern stops the next clippy_outN.txt / build-output dump from being committed the same way.
• A scan of the other pkgs/* package roots finds no sibling scratch dumps (the other tracked .txt files are resources/fixtures: schema files, migration text, mcpx .expected.txt fixtures), so this is a one-package cleanup, not a cross-repo set.

Why it matters

Half a megabyte of stale diagnostics sits in every clone and in every pkgs/id listing, and the contents are actively misleading: clippy_out5.txt reports lint errors (e.g. at src/commands/find.rs:212) that were fixed in the very commit that added the file, so anyone (or any agent) grepping the tree for open lint problems finds a phantom backlog that no longer exists. This is the same failure mode as #2464 (a stray agent-scratch file carried by a PR), except these reached main directly and have no guard against recurrence.

Acceptance criteria

• pkgs/id/clippy_out4.txt, pkgs/id/clippy_out5.txt, and pkgs/id/cargo-build-output.txt are deleted from the tree.
• A .gitignore guard (in pkgs/id/.gitignore or the repo root one) prevents committing the same scratch shapes again — at minimum clippy_out*.txt and cargo-build-output.txt at the pkgs/id root — without ignoring any legitimately tracked text file (benches/baseline.txt, proptest-regressions/, tests/regressions/, src/defaults.conf neighbours).
• After the change, git check-ignore / a fresh git status in a tree with a locally generated clippy_out6.txt shows it ignored, and the id crate's checks that read tracked text fixtures still pass (CI).
• No other file contents change.

Dedup

Searched open + closed issues for clippy_out, cargo-build-output, and scratch-file terms. #2464 (open) covers a stray get_plan.py at the repo root carried by PR #1715 — a different file, path, and landing path; it does not name these files. No existing issue covers the pkgs/id scratch outputs or a gitignore guard for them.