Keep the cockpit wheel with the view and let the native wheel recover

Found on a Quest 3 through Virtual Desktop (VirtualDesktopXR, Vulkan):
the race camera's view matched the scene camera exactly and the kart's
own wheel animated (228 draws a frame took the copy), but during the
race's opening pan no draw took it, the 30-frame fallback latched the VR
wheel for that vehicle, and it stayed until the scene changed.

The fallback now heals: copies keep being published, the VR wheel stands
in only while draws are not taking them, and the vehicle's own wheel
returns as soon as they are. Both switches are logged, a few per race.

With first_person_rotation "yaw_pitch" or "full" the wheel copy and the
hands' wheel geometry now ride in the view's own frame (the kart's
orientation around the seat) instead of the level seat, so the wheel no
longer tilts against the view on slopes.

Aurora logs, after about half a second, five seconds and a minute of
copies, how many draws bound a copied array (inside and outside its
window), how many matched, and the closest position matrix against the
expected one, so a mismatch says whether the array or the matrix differs.

OPENXR.md

@@ -352,15 +352,22 @@ the copy to the GX thread; Aurora substitutes it into the draws that bind that a
 player's own model-view matrix (`aurora_set_native_wheel_vertices`), checking each changed vertex's
 matrix slot, so an opponent sharing the asset and other joints of the same draw are untouched. The
 guest's own vertices are never written, and the copies are dropped after the frame's draws. Bikes
-turn their handle part in the game already; its copy is only re-seated on the level cockpit frame so
-the bars stay with your hands while the bike banks. If no draw takes the copy for 30 frames the log
-says so and the vehicle falls back to a separate VR wheel, which is also what
-`native_steering_wheel = false` draws.
+turn their handle part in the game already; its copy is only re-seated on the cockpit frame so the
+bars stay with your hands while the bike banks. The wheel rides in the same frame as the view: the
+level seat for `"yaw"`, the kart's own orientation for `"yaw_pitch"` and `"full"`. While no draw takes
+the copy (for 30 frames running; the race's opening pan does this) a separate VR wheel stands in,
+which is also what `native_steering_wheel = false` draws. The copy keeps being published, so the
+vehicle's own wheel returns as soon as draws take it again, and the log notes both switches.
 
 The copy is matched against the race camera's view (`RaceCamera::GetViewMtx` with no dolly offset),
 because the scene camera is only set once the draws run. The log reports, once a second, how far
 that view is from the scene camera at the seal (`[mkw-vr] cockpit: race camera view vs scene view`)
 and how many draws took the copy; the F10 bar shows the same under the steering-wheel settings.
+Aurora adds a line after about half a second, five seconds and a minute of copies
+(`Native steering wheel: N sets; draws binding a replaced array ...`) counting the draws that bound a
+copied array, those that bound one outside the window it was set for, the matches, and how far the
+closest position matrix was from the expected one; the first such line with a bound draw also prints
+both matrices.
 
 **Hand steering.** `hand_steering = true` (off by default; also in WheelWizard's OpenXR VR settings)
 lets you take hold of the wheel or handlebar with the tracked controllers. Squeeze a grip near it: