docker_lint.py --root mounts the live checkout, bypassing a repo's secrets-on-disk exclusion

[ptr727]

Symptom

A CodeRabbit review on ptr727/ESPHome-Config#115
(a hub resync carrying GOVERNANCE.md's "Running the Linters Locally" section, hub commit
3258284) flagged that its documented docker_lint.py invocation,
python3 /path/to/ProjectTemplate/scripts/docker_lint.py --root "$PWD", mounts the live checkout
straight into each lint container.

Root cause

docker_mount() in scripts/docker_lint.py binds the --root path as-is
(type=bind,"src={root}",dst={destination},readonly); it never builds a sanitized snapshot or
excludes git-ignored paths. Read-only stops the container from writing back, not from reading
whatever real files sit in the working tree.

Why this matters

ESPHome-Config's OPERATIONS.md already documents this exact hazard for third-party lint
containers generally, from a real past incident (secrets.yaml holding live device credentials,
git-ignored but present on disk): the fix there is to snapshot tracked-plus-intended-untracked
files into a temp dir first (git ls-files --cached --others --exclude-standard), then mount
that. docker_lint.py --root "$PWD" bypasses that protection when run literally as the hub's own
docs show it, in any repo that keeps a real secret file on disk alongside a tracked placeholder
(this pattern is not unique to ESPHome-Config).

Suggested fix

Either have docker_lint.py build its own tracked-plus-untracked-unignored snapshot before
mounting (consistent with how it already discovers lint targets via git ls-files/unignored
files elsewhere in the script), or add a documented --root caveat next to the invocation in
GOVERNANCE.md "Running the Linters Locally" pointing at the same snapshot pattern, so a repo
carrying that section verbatim doesn't have to know to add its own caveat.

Workaround applied downstream

ESPHome-Config#115 extends its own OPERATIONS.md "Repository Tooling Hazards" bullet to say
docker_lint.py --root must be the sanitized snapshot path, never the live checkout, since
OPERATIONS.md is this repo's own content and not hub-carried.

[ptr727]

Additional detail from ptr727/ESPHome-Config#116's review: the sanitized-snapshot workaround
doesn't actually solve this either, it just fails differently. docker_lint.py's own target
discovery (ls_files()) shells out to git -C "$root" ls-files, so a snapshot built by copying
git ls-files's own output (deliberately no .git, per the pattern this repo's OPERATIONS.md
documents) makes --root point at something that isn't a git repository at all: git -C fails
before any linter runs.

So today there's no way to run docker_lint.py safely against a repo carrying a real secret file
on disk: --root "$PWD" leaks it into the mount, and --root <snapshot> fails outright. Whatever
fix lands here needs to give the wrapper a target-discovery path that doesn't require .git
(a manifest file, or an explicit file list) as well as the mount-side sanitization the original
report asked for, or a snapshot has nothing to hand it.

[ptr727]

One more angle from ptr727/ESPHome-Config#116: .github/skills/comment-and-doc-style/SKILL.md
line 66 itself still says "Lint containers disable networking and mount the checkout read-only",
where OPERATIONS.md (per this same issue) requires a temporary snapshot, never the live
checkout. Worth fixing that wording alongside whatever wrapper change lands here, since a reader
of the skill file alone would still reach for --root "$PWD".