test: CPU occlusion-throttle measurement harness

[arzafran]

What this does

Adds the first CPU measurement harness for the "lean and speedy" workstream. It answers one question: how much CPU does the app burn with N busy terminal panes the user cannot see, compared to the same panes when they're visible. This is the baseline we need to actually prove the occluded-render throttle (ghostty fork 08bac45e9, PR #265, ~4Hz redraw cap for hidden surfaces) helps.

Zero shipped code. It's an external harness that drives an already-built, tagged app through the existing socket CLI and samples CPU from outside — nothing touches Sources/ or anything that ends up in the app bundle.

Summary

• tests_v2/test_cpu_occlusion_throttle.py: three scenarios built from existing socket commands (workspace.create/select, surface.split, surface.send_text, workspace.close):
  • hidden-busy — N workspaces each with one busy pane, occluded behind a different selected workspace (the throttle's actual target scenario)
  • visible-busy — the same N busy panes as splits in one visible workspace (control, capped at 6 panes)
  • idle — N hidden, non-busy panes (baseline)
• Methodology: samples cumulative CPU time via ps -o time= at the start and end of the window (not ps -o %cpu, which is a decayed average on macOS and misleads over a short window). cpu_percent = (cpu_time_delta / wall_time_delta) * 100. Reports the app process alone and app + PTY/shell descendants.
• Prints a table plus one JSON line per run so CI can diff numbers later. Never fails on "CPU was high" — only on a harness/socket error.
• Deliberately left out of tests_v2/ci_subset.txt (the curated PR-gating subset) — manual/dispatch-run only, same as the existing lag harnesses.
• docs/cpu-harness.md: how to run it against a tagged build, scenario descriptions, and the cumulative-CPU-time methodology note (including "compare medians of 3+ runs, one run is noisy"). Small pointer update in docs/testing-layout.md.

Test Plan

• python3 -m py_compile tests_v2/test_cpu_occlusion_throttle.py — passes
• git diff --stat against main — only tests_v2/ and docs/, nothing under Sources/
• First real use: run against a tagged build with the throttle on/off to establish the actual baseline numbers (follow-up, not part of this PR)