Dynamic shape explainer

[theHamsta]

Summary

• Describe the user-visible and code-level changes.

WIP implementation of webmachinelearning/webnn#945 basically adding the required API functions.

The .shape/.shape_with_options function existed already before this PR and where not guarded by feature = "dynamic-inputs. The shape op currently returns Vec<i64> instead of the u32 from the explainer. ORT and we used i64 internally but should probably switch to u32 from WebNN.

This PR will require some kind of shape validation. Either

• our existing, which may give up on dynamic shape resolution (e.g. yield unknown shape),
• or no build validation for dynamic shapes
• or a simple expression tree that is evaluated on computeShape
• or a fully symbolic constraint solver like z3 which is likely overkill but might help us for bring up by being mathematically correct and ready to use

Validation

• make test
• Relevant WPT or integration checks

Documentation

• Updated docs if behavior changed
• If backend converter/executor operator support changed, ran make docs-backend-ops and committed docs/development/backend-operator-support.md

[matthargett]

I've updated #223 against main and added exact-result tests for shape -> unsqueeze and integer-mask where. A few integration points from the CoreML work:

• I'd keep the existing int64 interchange path working while introducing the explainer's uint32 API contract. MIL shape returns int32, so this needs an explicit, checked backend boundary, not a blanket dtype change or feature gate on imported shape nodes.
• The latest clarification makes a small, shared Rust shape evaluator look like the useful next step: input shapes and selected constants only, with the same validation before dispatch. It is a side computation; the backend still receives the shape operators. It won't by itself fix the CoreML lowering gaps in Track SmolLM-135M CoreML blockers #222.
• A reduced shape -> unsqueeze graph with input [1, sequence<=8, 4] still hits the model-description/MIL-input shape mismatch when compiling on my M4. The Watch exporter work also showed why unknown dimensions, concrete defaults/ranges, and logical zero extents must stay distinct. In our CPU-only SE2/watchOS 11.6.2 runs, empty concat works with non-null backing; that isn't permission to replace zero with one or skip arbitrary empty operations (device results). Shape-product/byte-size arithmetic also needs checked conversions on arm64_32.
• MLResample2dDynamicOptions currently lacks the sizes operand. Could we add that, track it as an input dependency, and preserve axes/scales/sizes through interchange? That keeps Complete CoreML resample2d lowering #215's arbitrary-axis behavior intact when exchanging WebNN graphs.

Would tests comparing the host shape result with actual CoreML outputs be useful as the next shared validation step? I can help with those.