fix(awareness): ignore canvas input while the cockpit owns the camera

The cockpit turns Cesium's camera controls off and moves the camera on
its own, so a click, drag or wheel on the canvas moved nothing yet still
counted as the user handling the map: the cockpit's next move woke a
nine-second pulse burst. Input now counts only while the camera controls
take it, and a gesture still pending when another owner takes the
camera is dropped.

docs/CURRENT-STATE.md

@@ -4957,7 +4957,7 @@ silently demoting every later lookup for the session.
 - Enabled Data Layer controls report normalized feed health on the button (`LOADING`, `DEGRADED`, `STALE`, `FALLBACK`, or `UNAVAILABLE`) while the metadata line retains the source and reason. A partial CelesTrak group failure keeps the usable catalog and reports `DEGRADED`; a total outage keeps last-good catalog data visible but reports `UNAVAILABLE`.
 - On activation it focuses the nearest currently observed aircraft across the civilian and military feeds, with military winning an exact distance tie; if none are available, it focuses an observed AIS vessel. The aircraft search is deliberately uncapped and one refresh-tick retry handles initially empty feeds. This is an attention-priority navigation shortcut, not a high-risk, affiliation, or threat classification.
 - A selected aircraft, AIS vessel, or mapped installation gets a 250 km **context window** with nearby cohort counts, nearest examples, source labels, and stale/unavailable reasons. It emits `NEARBY` or `UNKNOWN`; no detection, engagement, affiliation, or sensor-activity conclusion is calculated.
-- The window's edge is drawn on the globe as a 250 km range ring: a 4 px polyline with a 2 px Context-blue core inside a 1 px dark halo on each side, 2.5 km above the ellipsoid (`AWARENESS_RANGE_RING_STYLE` in `src/layers/awareness/policy.js`). The halo keeps it legible over bright desert and snow, dark ocean and forest, and under the FLIR, NVG and CRT styles, where the earlier 1 px ellipse outline disappeared. It is a polyline because WebGL draws ellipse outlines at 1 px whatever width is asked for, drawn as an unpickable primitive rather than an entity so a click or tap on its edge reaches the contact underneath (headless viewers without a primitive collection get a static entity instead); it is rebuilt when the subject moves. Three dim sonar pulses (3 px with a 1 px dark outline, same colours, at most 60% opacity) grow slowly from the subject at constant speed, one every 3 s and each taking 9 s, and arrive at the ring at about a third of that. Behind each pulse a radial gradient in the same blue fades inward over 35% of the radius. One unpickable 250 km disc draws both the pulse lines and the gradient, its shader reading the pulse radii and opacities each frame, so a click or tap near a pulse still reaches the contact underneath; the disc follows the subject by a model-matrix rotation and is rebuilt only after the subject moves 20 km, and not at all while the pulses rest. While the camera is below the disc's 2.5 km height, where it would sweep across the sky, the pulses rest: the disc is hidden and there is no ring flash, no echo and no frame request. Terrain or 3D tiles higher than 2.5 km (the Alps, Andes, Rockies) still cut through the disc and the ring when seen from above, as the ring alone already did; the height check uses the camera's height above the ellipsoid, not above the ground. While pulses run, the ring dims to 40% and flashes to full strength as each pulse reaches it, fading over 1.8 s. As a pulse front crosses a flight, military aircraft or AIS vessel, the detection overlay draws a second bracket around that contact's own bracket, in the pulse blue on the default detection style and in the style's own line colour under NVG, FLIR and CRT, which spreads outward as it fades over 1.4 s (`AWARENESS_RANGE_ECHO`, read through `src/awarenessEcho.js`; no layer's icon is restyled, and mapped installations have no detection bracket). Pulses are born 5 km out, so the subject itself and anything nearer never echo. Pulses run for 9 s (three ring flashes) after a selection or a camera move, fading in and out over 1.2 s, then rest: the ring stays on screen at full strength, the pulses, gradient and echoes are hidden, and nothing asks for frames, so a parked Contacts view is quiet again. Only a camera move within 1.5 s of the user handling the map (pointer, wheel or touch on the Cesium canvas, which covers a drag's inertia; keys typed elsewhere do not count) wakes them; a moving subject and the app's own camera moves (a tracked aircraft, the cockpit view, an orbit, a fly-to) do not, since they move on every refresh. While they run they never hold continuous rendering: each drawn frame arms one render request 80 ms later (the Cyber sonar cadence, `CYBER_SONAR_RENDER_INTERVAL_MS`), so they repaint at about 12.5 fps and never beat the detection lane's 80 ms gate. Under `prefers-reduced-motion`, or in a scene without primitives or preRender and postRender hooks, there are no pulses or echoes and the ring stays on screen; changing the preference mid-session rebuilds the ring. The ring follows a moving subject once it has moved 250 m.
+- The window's edge is drawn on the globe as a 250 km range ring: a 4 px polyline with a 2 px Context-blue core inside a 1 px dark halo on each side, 2.5 km above the ellipsoid (`AWARENESS_RANGE_RING_STYLE` in `src/layers/awareness/policy.js`). The halo keeps it legible over bright desert and snow, dark ocean and forest, and under the FLIR, NVG and CRT styles, where the earlier 1 px ellipse outline disappeared. It is a polyline because WebGL draws ellipse outlines at 1 px whatever width is asked for, drawn as an unpickable primitive rather than an entity so a click or tap on its edge reaches the contact underneath (headless viewers without a primitive collection get a static entity instead); it is rebuilt when the subject moves. Three dim sonar pulses (3 px with a 1 px dark outline, same colours, at most 60% opacity) grow slowly from the subject at constant speed, one every 3 s and each taking 9 s, and arrive at the ring at about a third of that. Behind each pulse a radial gradient in the same blue fades inward over 35% of the radius. One unpickable 250 km disc draws both the pulse lines and the gradient, its shader reading the pulse radii and opacities each frame, so a click or tap near a pulse still reaches the contact underneath; the disc follows the subject by a model-matrix rotation and is rebuilt only after the subject moves 20 km, and not at all while the pulses rest. While the camera is below the disc's 2.5 km height, where it would sweep across the sky, the pulses rest: the disc is hidden and there is no ring flash, no echo and no frame request. Terrain or 3D tiles higher than 2.5 km (the Alps, Andes, Rockies) still cut through the disc and the ring when seen from above, as the ring alone already did; the height check uses the camera's height above the ellipsoid, not above the ground. While pulses run, the ring dims to 40% and flashes to full strength as each pulse reaches it, fading over 1.8 s. As a pulse front crosses a flight, military aircraft or AIS vessel, the detection overlay draws a second bracket around that contact's own bracket, in the pulse blue on the default detection style and in the style's own line colour under NVG, FLIR and CRT, which spreads outward as it fades over 1.4 s (`AWARENESS_RANGE_ECHO`, read through `src/awarenessEcho.js`; no layer's icon is restyled, and mapped installations have no detection bracket). Pulses are born 5 km out, so the subject itself and anything nearer never echo. Pulses run for 9 s (three ring flashes) after a selection or a camera move, fading in and out over 1.2 s, then rest: the ring stays on screen at full strength, the pulses, gradient and echoes are hidden, and nothing asks for frames, so a parked Contacts view is quiet again. Only a camera move within 1.5 s of the user handling the map (pointer, wheel or touch on the Cesium canvas, which covers a drag's inertia; keys typed elsewhere do not count, nor does input while Cesium's camera controls are off, as in the cockpit view, and a gesture still pending when the cockpit or another owner takes the camera is dropped) wakes them; a moving subject and the app's own camera moves (a tracked aircraft, the cockpit view, an orbit, a fly-to) do not, since they move on every refresh. While they run they never hold continuous rendering: each drawn frame arms one render request 80 ms later (the Cyber sonar cadence, `CYBER_SONAR_RENDER_INTERVAL_MS`), so they repaint at about 12.5 fps and never beat the detection lane's 80 ms gate. Under `prefers-reduced-motion`, or in a scene without primitives or preRender and postRender hooks, there are no pulses or echoes and the ring stays on screen; changing the preference mid-session rebuilds the ring. The ring follows a moving subject once it has moved 250 m.
 - For a selected live aircraft or vessel, the context window refreshes from the existing tracker/feed position every 750 ms, so nearest distances and cohort counts follow the subject without introducing a duplicate poll loop.
 - Aircraft cohort membership uses every locally loaded, selectable contact inside the 250 km window, including a plane hidden only by horizon culling or because its 3D model owns the visual. Counts and navigation therefore do not change with the current camera angle or billboard/model handoff.
 - Nearby examples in the context panel are focus controls: they use their owning layer's existing selection/tracking path, then frame that contact. Static-installation distances use ellipsoidal surface distance so the count matches the ground-projected context disk.

src/layers/awareness/lifecycle.js

@@ -14,13 +14,22 @@ export function createLifecycle({
    * Cesium canvas, where its camera controller listens), so a camera move the
    * user made can wake the range pulses and one the app made (tracking,
    * cockpit, orbit, a fly-to) does not. Keys are left out: Cesium's camera
-   * controller reads none, and typing elsewhere must not count.
+   * controller reads none, and typing elsewhere must not count. Nor does
+   * input while the camera controller's inputs are off: the cockpit (or a
+   * gizmo drag, or a drawing tool) owns the camera then, and the user's
+   * gesture moves nothing.
    */
   function noteCameraInput(event) {
     if (event?.type === 'pointermove' && !event.buttons) return;
+    if (!cameraInputsEnabled()) return;
     layerState.lastCameraInputMs = Date.now();
   }
 
+  function cameraInputsEnabled() {
+    const controller = layerState.viewer?.scene?.screenSpaceCameraController;
+    return controller?.enableInputs !== false;
+  }
+
   const CAMERA_INPUT_EVENTS = [
     'pointerdown',
     'pointermove',
@@ -79,6 +88,10 @@ export function createLifecycle({
       layerState.viewer.scene.preRender.addEventListener(() => {
         if (!layerState.enabled) return;
         const now = Date.now();
+        // Another owner took the camera: a gesture begun before it did must
+        // not wake the pulses on that owner's first move.
+        if (!cameraInputsEnabled())
+          layerState.lastCameraInputMs = Number.NEGATIVE_INFINITY;
         // "Did the camera move" uses the SAME quantized pose signature the fleet
         // rotation pass gates on (iconOrientation.cameraPoseSignature) rather than
         // camera.changed, whose granularity is globally degraded by other layers

src/layers/awareness/policy.js

@@ -92,7 +92,7 @@ export const AWARENESS_RANGE_RING_STYLE = Object.freeze({
  *  stays on screen, static, and nothing asks for frames, so a parked view
  *  goes quiet again. Only a camera move within `inputWakeMs` of the user
  *  handling the map (pointer, wheel or touch on the canvas, which covers a
- *  drag's inertia) wakes them; a moving subject and the app's own camera moves
+ *  drag's inertia, while the camera controls take input) wakes them; a moving subject and the app's own camera moves
  *  (tracking, cockpit, orbit, a fly-to) do not. Below the disc's height they
  *  rest too. While they run they never hold
  *  continuous rendering; each drawn frame arms one more request after the

src/layers/awareness/rangeRing.test.mjs

@@ -574,6 +574,99 @@ test('a camera move seen by the lifecycle wakes resting pulses; a parked camera
   assert.equal(state.lastCameraInputMs < Date.now() - inputWakeMs, true);
 });
 
+/**
+ * The lifecycle's camera-input listeners over `ring`, with a camera the test
+ * moves by longitude (`pan`) and a camera controller whose inputs it can
+ * switch off, as the cockpit view does. Pulses start resting.
+ */
+function inputLifecycle(t, ring) {
+  const { state, rendering } = ring;
+  const loop = frameLoop(t, ring, { date: true });
+  state.enabled = true;
+  state.viewer.canvas = new EventTarget();
+  state.viewer.scene.screenSpaceCameraController = { enableInputs: true };
+  state.viewer.camera = {
+    positionWC: Cesium.Cartesian3.fromDegrees(3, 20, 800_000),
+    heading: 0,
+    pitch: -1,
+    roll: 0,
+  };
+  const lifecycle = createLifecycle({
+    state,
+    services: {
+      render: { holdContinuousRender() {}, releaseContinuousRender() {} },
+    },
+    parts: {
+      rendering,
+      model: {
+        awarenessRefreshDecision: () => ({ moving: false, refresh: false }),
+        awarenessNeedsContinuousRender: () => false,
+      },
+    },
+  });
+  lifecycle.attachRuntimeListeners();
+  t.after(() => lifecycle.detachRuntimeListeners());
+  rendering.renderVisual(flight(3));
+  loop.advance(AWARENESS_RANGE_PULSE.activeMs + 500);
+  let lon = 3;
+  return {
+    loop,
+    lifecycle,
+    controller: state.viewer.scene.screenSpaceCameraController,
+    dispatch: (type, init = {}) =>
+      state.viewer.canvas.dispatchEvent(Object.assign(new Event(type), init)),
+    pan(stepDeg = 0.1) {
+      lon += stepDeg;
+      state.viewer.camera.positionWC = Cesium.Cartesian3.fromDegrees(
+        lon,
+        20,
+        800_000,
+      );
+      loop.draw();
+    },
+    /** Whether the pulses drew frames during the next `ms`. */
+    pulsing(ms = AWARENESS_RANGE_PULSE.activeMs) {
+      const before = ring.pulseFrames();
+      loop.advance(ms);
+      return ring.pulseFrames() > before;
+    },
+  };
+}
+
+test('input the camera controller ignores, as in the cockpit, does not wake the pulses', (t) => {
+  const ring = ringRendering(t);
+  const { activeMs } = AWARENESS_RANGE_PULSE;
+  const { controller, dispatch, pan, pulsing, loop } = inputLifecycle(t, ring);
+  // The cockpit takes the camera: clicks, drags and wheels on the canvas
+  // move nothing, while the cockpit itself moves the camera every frame.
+  controller.enableInputs = false;
+  for (const [type, init] of [
+    ['pointerdown', {}],
+    ['pointermove', { buttons: 1 }],
+    ['wheel', {}],
+    ['touchstart', {}],
+  ]) {
+    dispatch(type, init);
+    pan();
+    assert.equal(pulsing(), false, `${type} in the cockpit`);
+  }
+  // A gesture that began just before the cockpit took the camera is
+  // dropped too, rather than waking the pulses on the cockpit's first move.
+  controller.enableInputs = true;
+  loop.advance(activeMs);
+  dispatch('pointerdown');
+  controller.enableInputs = false;
+  pan();
+  assert.equal(pulsing(), false, 'a gesture cut off by the cockpit');
+  controller.enableInputs = true;
+  pan();
+  assert.equal(pulsing(), false, 'and stays dropped once it hands back');
+  // Back in the user's hands, a drag wakes them again.
+  dispatch('pointerdown');
+  pan();
+  assert.equal(pulsing(), true, 'a drag after the cockpit');
+});
+
 test('disabling the layer tears the pulses down completely', (t) => {
   const ring = ringRendering(t);
   const { state, scene, rendering, motion, pulseFrames } = ring;