Summary

Found by @trask on Windows: open-telemetry/opentelemetry-java-instrumentation#19183 (comment)

$ mise run lint:fix
[lint:fix] $ flint run --fix
Error: git check-attr

Caused by:
    The filename or extension is too long. (os error 206)

Two fixes for the same underlying bug class — passing many/long file paths as CLI args with no (or an inadequate) length cap, overflowing Windows' command-line length limits.

1. git check-attr (internal git-plumbing helper)

• generated_paths() passed candidate paths as CLI args to git check-attr, batched at 256 per invocation. On repos with many/long paths (e.g. opentelemetry-java-instrumentation, a deeply-nested Java monorepo) a batch can total tens of KB, exceeding Windows' ~32KB CreateProcess command-line limit (os error 206, ERROR_FILENAME_EXCED_RANGE — yes, that's the real Win32 constant's actual spelling; added a _typos.toml entry so typos stops "fixing" it to "EXCEED").
• Switches to git check-attr --stdin -z, writing paths to the child's stdin instead of argv — stdin has no OS command-line-length ceiling, so batching is no longer needed. Paths are written on a separate thread concurrently with reading stdout/stderr, since output can fill the OS pipe buffer before all paths are written, which would deadlock if done sequentially.

2. Scope::Files check invocations (general check-execution path)

While investigating, found the same bug class in build_invocations() — worse, actually, since it had no length cap at all (not even a fixed batch count):

• {FILES}/{RELFILES} was substituted with every matched file joined into one command. Many Scope::Files checks are mise shims routed through cmd.exe /C by spawn_command, and cmd.exe's own command-line buffer caps at ~8191 chars — tighter than CreateProcessW's ~32KB.
• google-java-format (registered via Check::files, no full_cmd fallback) is directly exposed: opentelemetry-java-instrumentation has thousands of .java files with long nested paths, so a PR touching as few as ~50 matching files could already overflow the limit. ryl, zizmor, xmllint, typos, and editorconfig-checker are similarly exposed. ktlint/dotnet-format have a full_cmd fallback, but it only applies to whole-project ("full") runs, not the common PR-scoped changed-files case.
• Adds chunk_files_by_length(), splitting matched files into groups that keep the rendered {FILES}/{RELFILES} argument under a conservative 6000-char cap, issuing multiple invocations instead of one unbounded one. run_invocations() already loops over a list of invocations and combines their output, so no changes were needed there.

Test plan

• check-attr: regression test with long-enough paths that a single 256-path argv batch would total ~56KB (verified mathematically, comfortable margin over the 32KB limit)
• Scope::Files: regression test constructing a check with enough long-named files that a single invocation would exceed the cap, verifying build_invocations splits into multiple invocations that together cover every matched file exactly once
• Both: this crate's own CI matrix (.github/workflows/test.yml) already runs cargo test on windows-2025, so these tests exercise the real failure mode there — can't reproduce the literal Windows OS error from a Linux sandbox, so margins were verified by calculation rather than direct repro
• cargo build, cargo test (272/273 pass; the one failure is a pre-existing environment gap — missing linter binaries on PATH in this sandbox, unrelated)
• cargo fmt --check, cargo clippy --all-targets -- -D warnings
• mise exec -- typos . clean