Both documented `within=` rules are load errors in the docs and no-ops in the loader

[FBumann]

What happened?

docs/reference/language/operators.md states two rules for a named window width, both as load errors:

• It is integral — a width counts positions rather than measuring a distance. dtype: int says so at load […] so a width of 2.5 has nowhere to arrive from.
• It does not span the dimension being summed over. A width that changes along that axis is a different window at every position, which is no longer "the last n".

Neither is enforced. This loads clean:

dimensions: { unit: { dtype: str }, hour: { dtype: int } }
parameters: { w: { dims: [unit, hour], dtype: float } }
variables: { x: { foreach: [unit, hour] } }
constraints:
  c:
    foreach: [unit, hour]
    expression: sum_back(x, over=hour, within=w) <= 1
objective: { sense: minimize, expression: sum(x) }

w is float and spans hour, the dimension being summed over — so it breaks both rules at once, and there is no error. Grepping for the checks turns up nothing: within appears in operators.py and dimensions.py's docstring only, never in resolution.py or validation.py.

Why it matters

The second rule is the load-bearing one. A width that varies along the summed axis is a different window at every position, so the operator no longer denotes "the last n" — but it still renders, as 0 ≤ t − t' < w, which reads as though w were a constant along that axis. The typeset math silently claims something the model does not say.

The first is milder but is what the docs offer as the reason a fractional width "has nowhere to arrive from".

What it should be

Both checked at load, in the language's own wording, on sum_back and sum_forward alike. Probably in resolution.py, which already types the dimension arguments and has the parameter's dtype and dims to hand.

Version

v0.0.0-alpha.10 (predates, and is inherited by, #56)