receipts: commit cross-reference queries only one local clone when a repo has multiple checkouts, undercounting/zeroing commits

## Summary

The `receipts` skill's transcript miner (`skills/receipts/scripts/mine-transcripts.mjs`) can report 0 commits for a project even when the user made and pushed many commits under their own git identity, if that project is checked out in more than one local directory (e.g. sibling worktree-style trees like `~/repo`, `~/repo.2`, `~/repo.3` cloned separately from the same remote).

## Root cause

Projects are bucketed by `path.basename(gitToplevel(dir))` (`projectForDir`), so multiple local clones of the same repo collapse into a single bucket keyed by directory name (e.g. `"rt"`). `filesTouched` is correctly unioned across all clones that contributed to the bucket, but the git cross-reference only queries **one arbitrarily chosen clone**:

```js
const dir = [...agg.cwd][0]; // first-inserted cwd wins
const raw = dir ? gitCommitsWithOurWork(dir, agg.filesTouched) : null;
```

Two failure modes follow from this:

1. If the picked clone hasn't fetched a commit that was pushed from a sibling clone, `git log` in that clone legitimately has no record of it — reported as a real "0 commits", not as a git error, even though the work landed.
2. Files that were only ever edited in a *different* clone than the one picked fail `gitCommitsWithOurWork`'s toplevel-prefix check and get silently dropped from the pathspec entirely, so they can never match a commit even if the picked clone's history is otherwise fine.

## Reproduction

- Clone the same repo into two local directories, e.g. `~/repo` and `~/repo.2`.
- Run Claude Code sessions that edit files and commit/push from `~/repo`.
- Run at least one other session (even just reading a file) from `~/repo.2`, without ever fetching there.
- Run the receipts miner. If the session that touched `~/repo.2` happens to be inserted into `agg.cwd` first, the report's commit count for the merged `repo` bucket comes from `~/repo.2`'s stale local history, not `~/repo`'s.

## Suggested fix

Query every clone in `agg.cwd` (not just the first), union the resulting commits by sha, and only fall back to `gitUnavailable` when no clone produced usable data. I've verified locally that querying all contributing clones and unioning by sha fixes the undercount without changing behavior for the single-clone case.