Add macOS parity reference evidence for the Partial ledger rows

[coneilen]

Problem

The Windows parity ledger has 35 Partial rows, and a large share of them were
stuck for the same reason: nobody had recorded precisely what the shipping macOS
app actually does. Windows sessions were implementing against prose in the
ledger rather than against observed macOS behavior — and at least one of those
sentences turns out to be misleading (see below).

What this adds

investigation/macos-parity-evidence/ — the captured answer, produced by running
the existing investigation/macos-parity-evidence-agent-prompt.md on a macOS
host against GraphCode 0.1.76 (299), built from
717240cdb373a2c00644842c429f06e520d15f51, which is the exact commit this
branch targets.

• macos-parity-evidence-report.md — row-by-row findings for all 35 Partial
  rows, verified requirements, Windows implementation candidates W1–W7,
  prerequisites/blockers, an explicit Not verified list, and an artifact index.
• evidence/ — 26 unaltered window captures, mapped to ledger surfaces.
• README.md — provenance and, importantly, the trust boundary.

Why it is trustworthy

Every claim in the report is marked S (inspected source), T (test source) or
R (direct observation of the running app), and confidence is rated on the
bounded finding rather than on blanket platform equivalence. Ten Swift
suites were executed once: 113 passed, 0 failed, 0 skipped. The report states
plainly that this is focused automated evidence, not a full make test.

It is equally explicit about what it did not establish. Terminal VT output,
IME, clipboard, Codespaces and a real update were deliberately not exercised and
are recorded as unobserved, not absent.

What it does not do

It does not validate any Windows code path, and no ledger row changes status
in this PR. A row still needs its own Windows runtime evidence to leave
Partial. I deliberately left the ledger untouched so this does not collide
with the parity sessions currently editing individual rows.

Two observed macOS behaviors are recorded as defects, not parity targets, so
Windows does not copy them: nested Main Rename… is offered but never opens its
alert (root-only lookup in ProjectFeature.swift), and the edge cycle-guard form
visibly clips its labels. macOS accessibility sample buttons were also found
unlabeled; Windows UIA should be fixed on its own merits.

Already load-bearing

One finding is immediately actionable and corrects the ledger. The Worktree notice chip row currently reads as though macOS excludes prunable worktrees
from its count. It does not:

Worktree inspection excludes the repository's canonical checkout by path,
not by branch. All remaining assessed rows contribute to count, including
prunable rows; only nonprunable rows contribute to size. Local and remote
sizing run du -sk, then multiply KiB by 1024. Thresholds are inclusive
8 linked/detached worktrees or 2 GiB by default.

The 7/8 notice boundary was observed live and is captured in
eight-worktree-notice-original.png and seven-worktrees-no-notice-original.png.
That row's owning session is correcting the text and its implementation
separately.

Privacy

investigation/** is covered by the always-on Investigation privacy scan.
Captures contain only disposable Alpha/Beta fixtures, an isolated bundle ID
and a temporary unregistered daemon — no real project, account, provider,
Codespace or release. The worktree sweeper's full-window capture was withheld by
the capturing agent because it renders a local path. I re-verified independently:
no NTFS alternate data streams, no local paths, no usernames or emails.

Size

This adds ~17 MB of PNGs, which is far larger than the existing
investigation/visual-baseline (~195 KB). I am flagging it rather than burying
it. I kept the files byte-for-byte as captured: recompressing or downscaling
would break the "unaltered original" property the report's evidentiary value
rests on. If reviewers would rather these live outside git history, say so and I
will move them — the report alone is 51 KB and carries most of the value.

Test plan

Documentation/evidence only; no product code changes. The privacy gate is the
real guard here, so I proved it actually fires rather than assuming it.

RED: planted $env:USERPROFILE + GraphCode-worktrees into a probe file under investigation/, then pwsh -NoProfile -File Tools\windows\validate.ps1 -Task privacy -> exit 1, "Environment-specific content matched 'C:\Users\coneilen'" (behavioral failure, not a compile error; probe then deleted)

GREEN: pwsh -NoProfile -File Tools\windows\validate.ps1 -Task privacy against the committed evidence -> "Privacy checks passed", exit 0

REGRESSION: pwsh -NoProfile -File Tools\windows\validate.ps1 -Task visual-baseline -> "VisualBaseline.Tests.ps1: PASS", exit 0; pwsh -NoProfile -File Tools\windows\validate.ps1 -Task tdd-evidence -> "TDD evidence: PASS", "TddEvidence.Tests.ps1: PASS", exit 0; git diff --check origin/main...HEAD -> no output, exit 0

Limits of this test plan

These runs validate repository hygiene and contract tests only. They establish
nothing about macOS or Windows runtime behavior. The macOS evidence in this PR
was captured on a separate host and is reproduced here as an artifact; CI does
not re-run it.

Correction. An earlier version of this description predicted the Windows and
macOS jobs would skip by path gating because this PR touches only
investigation/**. That was wrong, and the live run disproved it: windows-shell,
windows-spikes, macos and Linux build all ran.

The cause is correct fail-safe behavior, not a bug. Tools/ci/classify-changes.sh
treats *.md as docs-only, but .png matches no suite pattern and no docs-only
pattern, so each capture falls through to the final unclassified path branch and
calls all(). Reproduced locally against this PR's own file list:

git show --name-only --format= 10173c9f | bash Tools/ci/classify-changes.sh --event pull_request --stdin -> classify-changes: unclassified path '...evidence/alpha-composite-empty-original.png'; running every suite. (one line per capture), then windows=true macos=true linux=true

I am leaving the classifier alone. Running everything on an unrecognized path is
the safe default, and widening it to cover .png would be a separate change to CI
policy that this evidence PR should not carry. Recording it so the behavior is
understood rather than rediscovered.

Checklist

• Commits signed off (DCO)
• One change per PR
• Test plan states its limits honestly
• No product code, workflow, or ledger status changes
• Privacy scan passes on the added content