feat: Add multipath sequential modeling via PathSpec builder API

[kmdouglass]

This feature introduces a second way to build a SequentialModel alongside the existing from_surface_specs() convenience constructor: the PathSpec builder API.

SequentialModelBuilder::new()
    .paths(vec![path_t, path_r])
    .wavelengths(wavelengths.to_vec())
    .build()

Each PathSpec holds an ordered sequence of PathSurfaceRef entries, either New(SurfaceSpec) to introduce a surface into a shared SurfaceStore, or Shared(i) to reference a surface already committed by an earlier path. This allows multiple optical paths to share surfaces (e.g. both arms of a beam splitter share the same physical BS surface object and its placement).

PathSpec is a plain struct with public fields:

PathSpec {
    surface_refs: vec![
        PathSurfaceRef::New(SurfaceSpec::Object),
        PathSurfaceRef::New(SurfaceSpec::BeamSplitter { ... }),
        PathSurfaceRef::New(SurfaceSpec::Image { ... }),
    ],
    gaps: vec![
        GapSpec { thickness: f64::INFINITY, refractive_index: n_air.clone() },
        GapSpec { thickness: 100.0, refractive_index: n_air },
    ],
    beam_splitter_arms: vec![BeamSplitterPathKind::Transmitting],
}

BeamSplitter is now purely geometric: path_kind is removed from both SurfaceSpec::BeamSplitter and the BeamSplitter struct. Arm selection (Transmitting vs. Reflecting) is declared per traversal in PathSpec::beam_splitter_arms and exposed per iterator step via Step::bs_arm. The beam_splitter_arms field in the example above lists whether beam splitters should be transmitting or reflecting for this particular path. They are evaluated in order of the beam splitters specified

The existing from_surface_specs() constructor and all single-path models are unchanged. The GUI continues to use the convenience path.

For the moment, the feature isn't so useful as the Views only operate on the first path found. This is intended as a first step in an incremental implementation.