Title FPS controls need real keyboard-state input

[flyingrobots]

Problem

The title-screen FPS controls currently approximate held w/a/s/d with terminal key-repeat leases. That is not an FPS input model.

The failure mode is visible with jump and release cases:

• Hold s to move backward.
• Press jump.
• Release s while airborne.
• The camera can continue moving backward after landing because jedit never observed a real key-up event.

Earlier fixes on title/fps-input-continuity improved some symptoms, but they also made the core problem clearer: extending leases can smooth terminal repeat gaps, but it cannot distinguish "still held" from "released after action".

Current diagnosis

Bijou's raw KeyMsg currently exposes press-shaped keyboard messages only:

{
  type: 'key',
  key: string,
  ctrl: boolean,
  alt: boolean,
  shift: boolean
}

It does not expose keyDown, keyUp, or repeat for normal keyboard keys.

Bijou does have the semantic input-map API (InputDevice, InputFeature, createInputGestureRecognizer(), createInputActionMap()), but jedit is not using it for title FPS controls, and that API is currently built over the same press-only key stream.

Desired behavior

Title-screen FPS mode should behave like a real FPS input surface:

• w/a/s/d contribute to movement every frame while physically held.
• Any combination of WASD composes normally.
• Releasing a key removes that key from the movement vector immediately.
• Jump does not erase velocity.
• Crouch changes height/speed without chopping current momentum.
• Releasing all movement keys while airborne does not keep applying input after landing.

Acceptance criteria

• FPS title controls do not depend on text-editor key-repeat delay.
• There is an explicit key-state model for title FPS movement, or the feature is blocked on Bijou transport support and does not pretend otherwise.
• Regression coverage includes:
  • hold s, jump, release s, land: no continued backward input after release
  • hold w+a: diagonal movement while both are held
  • release a while holding w: forward-only movement continues
  • jump while holding w: horizontal velocity carries through jump
  • release w while airborne: velocity may continue physically, but no forward acceleration continues after release

Notes

This issue should not be resolved by adding longer leases. That path caused the exact "released key still acts held" bug.

[flyingrobots]

The title screen no longer renders on the startup path. As of 14d17b5 and 910373f on #304, jedit opens on an empty viewer, createInitialModelSnapshot loads no meshes and preloads no scene, and the ray-traced backdrop is reachable only by explicit opt-in (the scene picker, the title number keys, or an injected renderer). Two further fixes on #321 closed paths that were switching it on by accident — arrow keys and pointer movement both ran through activateLegacyTitleBackdrop.

This work is therefore no longer on any path a normal launch touches. It is deferred behind the Easter-egg opt-in, not obsolete.

Leaving it open and unlabelled rather than closing: the capability it describes is still real work if and when the ray-traced title returns as a deliberate feature. It just carries no urgency now, and should not be counted against the editor's day-to-day quality.