Speed up Debug builds: fix CI cache key + trim type-checker hotspots

[onevcat]

Summary

Two threads of work to shorten Debug clean-build wall time, especially on CI:

1. CI cache key fix — ~/Library/Developer/Xcode/DerivedData/CompilationCache.noindex
   was being cached with a static xcode-compilation-cache-v0 key.
   actions/cache@v4 only saves a new cache when the primary key has no
   exact match, so the cache was frozen at the very first snapshot ever
   written (~152MB, verified via gh api /repos/onevcat/Prowl/actions/caches).
   Most compile work didn't find its content hash in there, so CI kept
   cold-compiling almost everything. New key rotates only when
   Package.resolved or supacode.xcodeproj/project.pbxproj changes,
   so routine code-only PRs don't pay the ~30s upload cost but the
   cache still gets refreshed when its content profile actually shifts.
   restore-keys keeps the old -v0 snapshot reachable as a one-time
   fallback until the new -v1 cache lands.

2. Type-checker hotspots — profiling with
   -Xfrontend -warn-long-function-bodies=100 -Xfrontend -warn-long-expression-type-checking=100
   surfaced ~14s of cumulative type-checker time concentrated in a
   handful of files. The biggest mechanical wins:

   • Replace Dictionary(uniqueKeysWithValues: arr.map { ($0.id, $0) })
     with typed for-loops (huge generic-resolution reduction).
   • Promote the inline (repository:, worktrees:) tuple to a nominal
     ArchivedWorktreeGroup struct.
   • Extract complex SwiftUI bodies into private helpers so the
     result-builder accumulates less state per scope.

Type-checker hotspots (Debug, M2 Pro, threshold 100ms)

File / symbol	Before	After
ArchivedWorktreesDetailView.body	4312ms	346ms
CanvasView.body	1639ms	(below threshold)
WorktreeTerminalTabsView.body	344ms	301ms
ShelfOpenBookView.body	422ms	373ms
supacodeApp.init	356ms	(below threshold)
ToolbarNotificationGroup.toolbarNotificationGroups	315ms	(below threshold)
ListRuntimeSnapshotBuilder.makeSnapshot	301ms	368ms*
TargetResolver.makeSnapshot	314ms	315ms*

* The Dictionary-init hotspot is gone; the remaining time has shifted
to the surrounding outer body, which is a smaller per-file cost.

Build settings

• COMPILATION_CACHE_ENABLE_CACHING = YES at the project Debug
  level (was target-only). In practice SPM packages already inherit
  the cache via Xcode defaults so this is mostly belt-and-braces, but
  explicit is better than implicit.
• EAGER_LINKING = YES for Debug to overlap link with compile.

Wall-clock impact (M2 Pro 12-core, Debug)

Measured locally, two states each. The PR's biggest single CI lever is
the cache-key fix — local numbers conflate it with the existing warm
local cache, so the delta below is the realistic shape of what CI
should see once the new -v1 cache populates.

Scenario	Wall	Cumulative SwiftCompile
Cold cache (custom DerivedData, before changes)	~44s	162.8s
Cold cache, after code refactoring	~41s	154.9s
Warm cache (default DerivedData)	~17-18s	~10s

Code-level refactoring on its own buys ~5% on cold; the dramatic
drop comes from the cache actually being usable, which is what the CI
fix unlocks.

CI impact

Once the new -v1 key populates after merge, subsequent runs should
restore a much fuller cache and skip most SwiftCompile work. The key
rotates only on dep / project-file changes, so routine PRs hit primary
key → restore → build → no re-upload (avoids per-run ~30s save cost
and CI minute charges). Stale or harmful caches can be wiped via the
GitHub Actions cache UI; the next CI run rebuilds a fresh -v1 from
scratch.

Test plan

• make build-app
• make lint (SwiftLint strict)
• make format-lint (swift-format strict)
• xcodebuild test -only-testing:supacodeTests/ToolbarNotificationGroupingTests
• Full CI run on this PR — verify cache save-back triggers (cache list should show a new -v1-<hash> entry)
• Re-run CI after first save - confirm restore hits and build is faster
• Manual smoke: launch Prowl, open a repo, open archived worktrees pane, open canvas, switch tabs