Let pointer presses reach the keyboard stage's hit targets

[malpern]

Summary

Clicking a key in the onboarding tour did nothing whenever Metal was active (the shipped default). KeyboardStageMTKView is a real NSView with no hitTest override, so it returned itself for every point inside the keyboard and swallowed mouse events before the semantic overlay's per-key hit targets — which sit above it and own pointer interaction — could receive them.

• Return nil from hitTest, matching the plan's boundary that the renderer is visual output only
• Regression test pinning the contract, verified failing without the fix

Note on how this survived

Snapshot/golden coverage renders scenes but never exercises input, so no automated test could catch a pointer-routing defect in the Metal path. Worth follow-up interaction-level coverage; see PR discussion.

Review gate

remote review gate selected — GitHub claude-review is the enforced reviewer.

Testing

• KeyboardStageInteractionTests pass (6); the new test fails without the fix and passes with it

🤖 Generated with Claude Code

[claude]

Review of the diff: the fix (override hitTest to always return nil on KeyboardStageMTKView) is a reasonable way to stop the Metal render view from swallowing clicks meant for the semantic overlay above it, and the new test correctly pins that behavior for a couple of sample points.

One thing worth confirming before merge: this override makes the Metal view unconditionally transparent to all pointer-driven interaction, not just clicks — that also affects mouseMoved/cursorUpdate, right-click/context-menu routing, and any drag or magnify/scroll gesture recognizers that might be attached directly to this view. If the Metal view (or a gesture recognizer on it) is ever relied on for pan/zoom, hover cursor changes, or a context menu on the keyboard stage, this change would silently break those too, since AppKit hit-tests the frontmost view first and now always skips this one. If none of that applies today, it'd be worth a one-line comment near the override stating that explicitly (the existing doc comment covers why clicks needed to pass through, but not the fact that it disables all other pointer-derived interaction as a side effect), so a future contributor adding a gesture to this view doesn't get silently defeated by it.

Test coverage is otherwise adequate for the specific regression being fixed (constructs the view directly and checks hitTest at two points); no correctness issues found in the test itself.