Four tests fail on a clean v2 checkout on macOS (t255, t276, t314, t325)

Four test files fail on an unmodified `v2` checkout on macOS. Filing them together because they were found the same way — establishing a clean baseline before opening #968 — and because three of the four look like the same root cause class (a platform assumption rather than a logic error).

Not urgent, and not blocking anything of mine. I have no fix to offer for any of them; this is a reproduction report so they are on the record rather than living in my notes.

## Reproduction

```bash
git checkout v2 # 82d2e304 at time of writing
bun install
bun tests/run-tests.ts --smoke --unit # 274 files -> 3 failed
bun tests/run-tests.ts --integration --no-llm # 114 files -> 1 failed
```

Environment: macOS 15 (Darwin 25.6.0), arm64, bun 1.3.14, `AIDLC_NO_LLM=1`.

**Run the integration tier SERIALLY.** With `--parallel 8` I saw `t188-plugin-compose` and `t327-team-dispatcher` fail too; both pass serially, so those two are load artifacts and are *not* included below.

## The four

| file | tier | failing assertion(s) |
|---|---|---|
| `t255-workspace-sync` | unit | `ignored, config-hidden, and index-hidden files BLOCK --force removal`; `live remote queries reject stale refs, local tags, and reflog-only commits`; `secondary worktrees, submodules, and LFS object stores BLOCK removal`; plus 4 more in the same describe |
| `t276-cursor-adapter` | unit | `29: Windows evaluator variants and unresolved expansion remain fail-closed`; `35: Git inspection follows reachable compound-command cwd state` |
| `t314-source-freshness-receipts` | unit | `swarm source and exclusion batching stay below Windows command-line limits` |
| `t325-team-unit-claims` | integration | `partial clones explicitly hydrate claim payload blobs with lazy fetch disabled` |

## What they look like from outside

- **`t276` and `t314`** both assert **Windows-specific** behaviour (`Windows evaluator variants`, `Windows command-line limits`) and both are in files touched by the recent Cursor-hardening and source-freshness work. My guess is a Windows-path assumption that does not hold when the test runs on macOS, rather than a defect in the shipped behaviour — but that is a guess, and I have not read the assertions closely enough to claim it.
- **`t325`** exercises `git` partial-clone / lazy-fetch behaviour, which varies by git build. Mine is Apple git.
- **`t255`** is the one I understand least. Its failure count varies run to run (7 or 8 assertions), and one of the flaky ones is `orphan changes during a slow clone abort the transaction` — a timing-sensitive name. It may be partly environmental.

## Why this is worth a few minutes of yours

These are the only failures on a clean `v2`, so anyone establishing a baseline before contributing hits exactly this set and has to work out for themselves which failures are theirs. That cost me a couple of cycles on #968 — I twice mis-attributed a pre-existing failure to my own branch and once compared a parallel run against a serial baseline. A note in `docs/reference/09-testing.md` saying "these N are known to fail on macOS" would have saved all of it, if a fix is not worth it.

Happy to gather more detail on any of the four if that helps — I have the full runner output.

Start by running the serial unit and integration commands in tests/run-tests.ts on the reported macOS environment. Read t255-workspace-sync, t276-cursor-adapter, t314-source-freshness-receipts, and t325-team-unit-claims to isolate platform or environment assumptions. Done means fixing the reproducible failures or documenting the known macOS baseline in docs/reference/09-testing.md.

Written by the indexing model from the issue text.