fix: don't let git ignore rules override tracked-file inclusion

[dduugg]

What is this change doing?

1. Disables git_global, git_ignore, and git_exclude on the WalkBuilder used in project_builder.rs, and adds a regression test.
2. Fixes the failing audit workflow: replaces the archived actions-rs/audit-check@v1 with the maintained fork rustsec/audit-check@v2.0.0, and overrides RUSTUP_TOOLCHAIN to stable for that job only.
3. Updates crossbeam-epoch and tracing-subscriber in Cargo.lock to patched versions, per two real advisories the now-working audit job surfaced.
4. Bumps the crate version to 0.3.4.

Why is this change being made?

(1) Directory-walk fix: generate's directory walk honors git's own ignore semantics (a personal global core.excludesFile, local .gitignore, and .git/info/exclude) in addition to the tool's own tracked_files check (git ls-files). If a directory is force-tracked despite matching one of those rules, the walker prunes it before the tracked-files check ever runs — silently dropping its ownership entries from the generated CODEOWNERS.

This is nasty in practice because it's machine-dependent: whether a given repo's CODEOWNERS regenerates correctly depends on whether the developer running it happens to have a personal global gitignore rule that collides with something force-tracked in the project. I hit this directly: a personal ~/.gitignore_global containing a blanket .claude/ rule (unrelated to any specific project, just personal declutter preference) caused generate to silently drop 4 legitimate, git-tracked .claude/** ownership entries from a real CODEOWNERS file — on my machine only. CI (no such global config) generated the correct output, which made this very confusing to track down: validate failures that only reproduced on one machine, with a completely clean/unmodified checkout.

.ignore files are left enabled — those are this tool's own opt-in exclusion mechanism (see tests/fixtures/valid_project/.ignore), which is unrelated to git tracking status and shouldn't be touched by this fix.

(2) Audit workflow fix: the audit job was failing outright (see this run):

rustc 1.89.0 is not supported by the following package:
  kstring@2.0.4 requires rustc 1.96.0

Two compounding problems:

• actions-rs/audit-check@v1's org is archived/unmaintained, so any upstream fix there is a dead end. Replaced with the actively maintained fork, rustsec/audit-check@v2.0.0 — same token input, drop-in swap.
• That alone didn't fix it: the 1.89.0 in the error isn't ubuntu-latest's default Rust, it's this repo's own rust-toolchain.toml pin (used to build the actual crate), which rustup applies to every cargo invocation from within the repo, including the audit action's internal cargo install cargo-audit. Latest cargo-audit's dependency tree now needs a newer rustc than that pin provides. Fixed by setting RUSTUP_TOOLCHAIN: stable as a job-level env var — it overrides the directory-level toolchain file for just this job, so cargo-audit gets a current toolchain without touching the pin the rest of CI builds against.
• The job log also carries a Node 20 deprecation warning — that's unrelated noise from the runner's own actions runtime, not the actual failure cause.

(3) Dependency advisories: once the audit job could actually run, it immediately found two real advisories already present on main, unrelated to anything else in this PR:

• RUSTSEC-2026-0204 — crossbeam-epoch invalid pointer dereference in fmt::Pointer/fmt::Display, fixed in 0.9.20 (we were on 0.9.14).
• RUSTSEC-2025-0055 — tracing-subscriber ANSI escape sequence injection in logs, fixed in 0.3.20 (we were on 0.3.19).

cargo update -p crossbeam-epoch -p tracing-subscriber pulled in the patched versions with no code changes needed. (Two additional "unsound" advisories on anyhow/error-stack are informational-only per cargo-audit and don't fail the check; left alone.)

(4) Version bump: for release, now that everything above is in.

How did you test this change?

• Added tests/global_gitignore_test.rs, using a .git/info/exclude rule as a reliable stand-in for the global-gitignore repro (avoids fighting $HOME/core.excludesFile resolution in a sandboxed test). Confirmed it fails without the fix and passes with it.
• cargo test — full suite (133+ tests) passes after every change in this PR, including the dependency bumps.
• cargo clippy --all-targets --all-features -- -D warnings and cargo fmt -- --check — clean (enforced by the repo's own pre-commit hook) after every commit.
• Manually reproduced the directory-walk bug against a real fixture with a real global core.excludesFile before narrowing to the more portable .git/info/exclude repro used in the test.
• Iterated on the audit fix against CI directly: the action swap alone still failed with the same rustc error, which is what surfaced the rust-toolchain.toml pin as the real cause; adding the RUSTUP_TOOLCHAIN override got the job actually running, which is what then surfaced the two real advisories fixed in (3).