Land the press-rebound fix that raced the #1248 merge

[malpern]

Summary

#1248 was merged three minutes before its final review-fix commit was pushed, so master carries the press-physics pass with two known defects this commit fixes:

• The release rebound was dead code for a plain tap (signed press level collapsed by max() before the guard); now gated on components with a scene-level regression test
• The capsApplying authored echo pose overwrote the press travel; travel now applies on top

Cherry-pick of 8efc9a1 from the merged branch, unchanged.

Review gate

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

Testing

• Scene/interaction/entrance suites pass (44 tests) including the new rebound regression test; snapshot suites stable

🤖 Generated with Claude Code

[claude]

Reviewed the diff — both fixes look correct and the added test targets the right behavior.

• KeyboardStageSceneBuilder.swift: good catch. The old code set translation.y = 0.12 * 0.023 and then immediately overwrote the whole translation with KeyboardStagePoint(x: -0.48, y: -0.52), silently discarding the indent offset. Folding it into -0.52 + 0.12 * 0.023 is the right fix.
• KeyboardStageInteraction.swift: gating on abs(pressLevel) > 0.001 || abs(holdLevel) > 0.001 instead of abs(max(pressLevel, holdLevel)) > 0.001 correctly stops discarding the release-rebound frames (negative pressLevel, zero holdLevel) that previously collapsed to 0 and got skipped.
• New test testReleaseReboundLiftsTheCapAboveRest covers the interesting case (negative pressLevel, zero hold) and checks interactionLevel == 0 / pressure unchanged, which matches the "no residual press styling" intent.

Minor/non-blocking nits:

• max(pressLevel, holdLevel) is now computed twice (once implicitly via the two abs checks, once again for interactionLevel) instead of reusing a single level local like before — purely stylistic, no behavior issue.
• The new test doesn't assert on opacity, which this same code path forces to max(_, 0.98) even during the negative-rebound frames it's exercising — worth a follow-up assertion if that opacity floor during rebound is intentional, just to lock in the expected visual (currently slightly brightened key while it's rebounding past rest).

No actionable correctness/reliability/security issues found.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 600ad846f6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid retaining pressed opacity during the negative rebound

When a tapped key's authored opacity is below 0.98 (including most standard and dimmed keys), allowing its negative pressLevel through this guard also executes responsiveKey.opacity = max(responsiveKey.opacity, 0.98). The rebound frame therefore has zero interaction level and pressure but remains visibly highlighted until it abruptly returns to its base opacity when the transition settles, contrary to the intended no-residual-press-styling behavior. Apply the signed level only to the translation rebound, or gate the opacity boost on a positive press/hold level.

Useful? React with 👍 / 👎.