Background review enqueue spawns one git hash-object process per dirty path, so a large dirty tree makes enqueue slow

[patriyang]

Observation

captureRepoStateIdentity (added in #101, closing #98) fingerprints a working-tree review target so a queued background review can refuse to run once the repository has moved under it. Building that fingerprint hashes content per path:

• each dirty tracked path goes through git hash-object --no-filters -- <path> (plugins/codex/scripts/lib/git.mjs, hashWorkingTreePath)
• each untracked regular file goes through the same, one call at a time (hashUntrackedPath)

Every one of those is a separate synchronous spawnSync. The cost is O(dirty paths) process startups, paid inline on the --background enqueue path — the interactive call the user is waiting on before the command returns a job ID.

Impact

Enqueue latency only; no correctness issue. It is invisible on a handful of changed files and grows linearly. A tree with hundreds of untracked or dirty files (a fresh build output directory that is not ignored, a large generated fixture set, a vendored dependency dump) makes /codex:review --background and friends noticeably slow to return.

Repositories where git status --porcelain is already slow will feel it worst, since the fingerprint work lands on top of that.

Context

• Raised by Codex code-quality review on Retry capacity rejections on a designated backup model, and refuse a review whose repository moved #101 as a Minor finding, and left unaddressed there deliberately — the PR was already at its review-round cap and this is a performance concern, not a correctness one.
• The fingerprint itself is not optional: it is what closes the false-negative described in A queued background review pins its target's scope but not the repository state, so a commit before the worker starts can silently review nothing #98, where a queued review could report a clean result for a change it never saw.

Non-prescriptive notes

git hash-object accepts multiple paths in one invocation and emits one OID per line in argument order, which would collapse the tracked and untracked passes into a small constant number of processes. Anything batched would need to stay clear of platform argument-length limits — chunking, or feeding paths on stdin with --stdin-paths, rather than one unbounded argv.

Whatever shape is chosen should keep the current per-path semantics intact: symlinks, directories/gitlinks, and unreadable or missing paths are handled separately from regular files today, and the submodule branch folds in that submodule's own HEAD and diff content.