Deferred: correct baked-in diSPIM view-geometry assumptions (asymmetric views, XZ/YZ projections)

[subindevs]

Part of #50 (device-layer refactor) — deferred phase. Depends on the AO-adiSPIM
hardware profile (#81) existing first.

Problem

The diSPIM plugin bakes in view-geometry and frame-layout assumptions that are only
valid for the standard/Gently diSPIM. A second scope with asymmetric views exposes them
as latent bugs (per @ceej640's analysis in #50):

• Dual-view frames treated as equal-width stitched halves ("physical View A / View B"
  in comments), with focus/vision helpers often selecting the brighter half —
  assumes equal physical scale/FOV across views.
• Coordinate conversion uses default pixel-size/magnification values rather than a
  per-view geometry model.
• Perception renders three orthogonal XY/YZ/XZ projections, and the C. elegans
  perception prompt gives biological meaning to vertical/horizontal structure in XZ. If a
  volume is oblique in camera space relative to lab-frame XYZ, generated XZ/YZ
  projections may not mean the same thing — plausibly fooling perception unless the volume
  is deskewed/reoriented or the prompt/model is calibrated for that geometry.
• No explicit view-geometry model (per-view angle, per-view pixel scale, camera
  orientation, splitter layout, camera-space → lab-space transform).

Goal

Once the hardware profile (#81) declares per-view geometry, retrofit the diSPIM
view-handling and perception projection paths to consume it instead of assuming
diSPIM-specific defaults.

Why deferred (rule of three, from #50)

This touches the perception path and C. elegans prompt semantics — high blast radius.
Do it as a second abstraction pass driven by what the profile actually exposes,
rather than guessing the right shape from diSPIM alone. Keep validating on the real
diSPIM throughout to catch regressions.