Saved courses in menu races

The ordinary game menus now resolve their three courses through TrackCatalog and the baked resource Tracks/TrackAuthoring. Editing a track scene is no longer limited to its direct Editor Play session.

Authoring and building

1. Open the appropriate scene under Assets/Rampage/Scenes/Tracks.
2. Edit its child SplineContainer knots or tangent handles. Keep the course closed with at least four knots, then save the scene.
3. Run RAMPAGE → Bake saved courses for menu races, or run the normal project Configure/Build command. Configure calls TrackAuthoringBake.BakeAll() after ensuring the scene entries exist.
4. For a release, commit the saved scenes and generated Assets/Rampage/Resources/Tracks/TrackAuthoring.asset, then run Tools/build.ps1 -Action ReleaseBuild.

Baking opens saved scene copies through OpenPreviewScene. Unsaved changes in another open scene are not included. The bake validates all three courses before replacing the previous asset. Each record contains its source scene path and SHA-256, along with the route data. Open splines, non-finite knots/handles/transforms, and invalid sampled routes stop the bake with an error.

Release builds call TrackAuthoringBake.ValidateForRelease() without writing assets. Missing, dirty, or stale baked data stops the release; freshly resolved saved-scene snapshots must match the asset. Commit checks still apply independently.

Preserving the existing tracks

The initial Unity spline knots and handles reproduce the original Catmull–Rom curves. If those knots and transformed handles remain unchanged, the bake records UseOriginal and the game keeps the original catalog sampling exactly. The comparison permits 1 mm of floating-point serialization tolerance. Edited routes use a closed dense sample of the actual saved Unity spline, including its transform and tangent edits.

The catalog's original definitions are kept separately from its loaded runtime definitions. Resetting an editable spline uses the original definition, so the previous bake cannot become its own reset baseline. Both direct scene play and the normal menu path preserve the course ID, biome, presentation metadata, and shared checkpoint/AI systems.

The runtime uses the original catalog if no baked resource exists, allowing an initial editor setup. A committed release requires the validated bake. After an edit, track previews and driving/landmark clearance still need review; the bake does not certify an arbitrary new layout as drivable.

Verification

Run Tools/build.ps1 -Action VerifyAuthoring after Configure. This invokes Rampage.Editor.TrackAuthoringVerification.Run with no graphics device and writes Docs/QA/track-authoring-verification.json.

The harness checks the saved production snapshots, all three runtime course seams and ordered gates, unchanged seed preservation, and a temporary saved scene with an edited knot and handle. That fixture is baked, serialized as a temporary Resources asset, and loaded through the same catalog resource path as the game. It checks that the runtime road passes through the edited knot and still counts ordered laps. It also rejects open/non-finite authored splines, checks close camera obstruction distances, and verifies that the three original scene hashes remain unchanged. Temporary fixtures are removed afterward.

These are source/asset and production-sampler checks. They do not render frames, simulate physical driving, or establish GPU stability. The sources passed offline Runtime/Editor compilation during implementation; execution of this new Unity harness is pending. Current integrated acceptance remains documented in QA-RESULTS.md.