feat(rhi): a pipeline that generates its own vertices can cast a shadow

[CagdasErturk]

PipelineDesc::depth_only(vertex_spirv, vertex_count) — no per-vertex stream, no fragment stage, no colour attachment.

Until now that shape could not be spelled. The only depth-only constructor hard-sets vertex_input: Some(layout), and the frame contract asserts that an item names geometry exactly when its pipeline declares per-vertex input:

an item names geometry exactly when its pipeline declares per-vertex input — a mesh
pipeline with no mesh reads an unbound binding, and a mesh on a pipeline that generates
its own vertices is ignored

So a pipeline that writes its own vertex list and draws an instance stream could reach a colour target and no depth-only one. A renderer of that shape could be seen and could not cast, which is not a limitation anybody chose.

Two tests, at two distances from the hardware

The unit test pins that the two depth-only shapes differ in exactly one field, and that it is the one Item's rule reads. vertex_input is not a detail of these constructors — it is the whole difference between them, one demanding geometry and one demanding its absence.

The device test builds the pipeline and submits a depth pass whose item names no geometry, with no validation error. It deliberately does not read the depth back, and says so in its doc: the only stage available here writes z = 0.0, which under reversed-Z is the clear value, so a readback cannot separate a draw that happened from one that did not. Claiming otherwise would be a test that looks like it checked something.

Probes

Both watched red and restored. Swapping depth_only for depth_mesh makes the frame contract refuse the item, in the words that made this constructor necessary. Giving depth_only a vertex input makes the unit test name the refusal it would cause.

cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings and cargo test --workspace all green on a real adapter with validation active, exit codes read directly.