Identifies non-executable lines (comments, blank lines, brackets, etc.) in tracked source files and uploads them alongside coverage reports so the backend can exclude them from coverage calculations.

What and why?

Code coverage reports sometimes flag non-executable lines (comments, blank lines, closing brackets, etc.) as "uncovered", creating false negatives. This PR adds file fixes — a bitmap per source file marking which lines are non-executable — so the backend can exclude them from coverage calculations.

How?

During datadog-ci coverage upload, the CLI:

1. Lists all git-tracked files (git ls-files) and filters to supported languages (Go, Kotlin, C/C++, Swift, ObjC, PHP)
2. For each file, scans lines against language-specific regex patterns (empty lines, comments, block comments, brackets, etc.)
3. Encodes matches as a 1-bit-per-line bitmap (base64-encoded) per file
4. Uploads the result as a gzipped JSON payload (file_fixes.json.gz) alongside the coverage report

File discovery uses two strategies:

• Default (git ls-files): fast, respects .gitignore, only tracked files. Used when running inside a git repo without --file-fixes-search-path.
• Filesystem walk fallback: recursive directory traversal, skipping common non-source folders (node_modules, .git, .venv, etc.). Used when git is not available or --file-fixes-search-path is provided. This is useful in monorepos to scope the scan to a specific subdirectory.

Files are processed concurrently (8 async workers).

New CLI flags:

• --disable-file-fixes — skip file fixes generation entirely
• --file-fixes-search-path — override the root directory used to scan source files (defaults to repo root). Triggers the filesystem walk instead of git ls-files.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)