`BENTLEY_materials_line_style` dash patterning ignores `CUMULATIVE_DISTANCE` on `LINE_STRIP` primitives

## Summary

`MaterialPipelineStage` only enables the cumulative-distance parametrization path for line-style dash patterns when the primitive type is `LINES` or `TRIANGLE_STRIP`. Primitives with mode `LINE_STRIP` are excluded, so even when a `BENTLEY_materials_line_style:CUMULATIVE_DISTANCE` vertex attribute is present, the shader could silently fall back to **screen-space patterning** (the dash pattern is parametrized by viewport X/Y instead of distance along the line). The fallback is view-dependent: the pattern crawls as the camera moves and stretches on diagonal lines.

## Affected code

`packages/engine/Source/Scene/Model/MaterialPipelineStage.js`, `processLineStyleUniforms()`:

```js
if (
defined(pattern) &&
defined(cumDistAttribute) &&
(primitive.primitiveType === PrimitiveType.LINES ||
primitive.primitiveType === PrimitiveType.TRIANGLE_STRIP)
) {
// HAS_LINE_CUMULATIVE_DISTANCE path — dash pattern follows distance along line
} else if (defined(pattern)) {
// screen-space fallback — view-dependent, lower quality
}
```

`PrimitiveType.LINE_STRIP` never reaches the `HAS_LINE_CUMULATIVE_DISTANCE` branch.

## Why this matters now

`BENTLEY_materials_line_style` tileset export could output with a per-vertex `BENTLEY_materials_line_style:CUMULATIVE_DISTANCE` accessor attached to:

- `LINES` primitives (`AddLine`) — ✅ handled correctly by CesiumJS today
- `LINE_STRIP` primitives (`AddLineStrings`, batched via primitive restart) — ❌ hits this gap

Line-string data produced with primitive restart batching (`EXT_mesh_primitive_restart` today, `KHR_mesh_primitive_restart` per KhronosGroup/glTF#2569 going forward) uses mode `LINE_STRIP`, so this is exactly the styled-line content that will be produced at scale.

## Expected behavior

A `LINE_STRIP` primitive with a line-style `pattern` and a `CUMULATIVE_DISTANCE` attribute should use the cumulative-distance parametrization (`v_lineCoord` derived from the attribute), matching the behavior of `LINES` primitives.

## Actual behavior

The dash pattern is computed from screen coordinates. Rendering succeeds, but the pattern does not track distance along the line, changes with camera motion, and is inconsistent between line segments of different orientations.

## Proposed fix

Add `PrimitiveType.LINE_STRIP` to the primitive-type condition in `processLineStyleUniforms()`. Verify:

- Correct interaction with primitive restart values in the index buffer (restart indices reference no vertex, so per-vertex distances are unaffected; each sub-string's distances are baked by the writer).
- The normalized/quantized attribute variant (`LINE_CUM_DIST_NORMALIZED`) also works for `LINE_STRIP`.

## Test coverage

- Add a spec with a `LINE_STRIP` primitive + `BENTLEY_materials_line_style` pattern + `CUMULATIVE_DISTANCE` attribute asserting `HAS_LINE_CUMULATIVE_DISTANCE` is defined in the shader.
- Ideally include a variant whose index buffer contains primitive restart values (revised `KHR_mesh_primitive_restart` style) to cover the batched-line-string case.

## Related

- KhronosGroup/glTF#2569 — `KHR_mesh_primitive_restart` spec proposal
- Existing fixture: `Specs/Data/Models/glTF-2.0/StyledLines/BENTLEY_materials_line_style.gltf`

Start in packages/engine/Source/Scene/Model/MaterialPipelineStage.js at processLineStyleUniforms() and inspect the existing LINES and TRIANGLE_STRIP condition. Add coverage for the existing StyledLines/BENTLEY_materials_line_style.gltf fixture or a LINE_STRIP spec, including the normalized attribute variant and, if feasible, primitive restart. Done means the shader defines HAS_LINE_CUMULATIVE_DISTANCE for LINE_STRIP primitives with the cumulative-distance attribute.

Written by the indexing model from the issue text.