Should a named `shift` offset be required to declare an `edge=`?

[FBumann]

Split out of #62, whose other two rules are fixed in #63. This one is a design decision rather than a bug, which is why it is separate.

The documented rule

operators.md, on a named offset:

it says what the vacated positions contribute — edge='wrap' or a number. The bare form's absence is carried by a frame keyed by the translated dimension alone, and a per-entity offset vacates a different slot for each entity, which that frame cannot yet say.

It is unenforced: shift(x, over=hour, offset=lead) with no edge= loads and renders as x_{u,h - \mathrm{lead}}.

Why it isn't simply a bug

The justification is a downstream limitation — what a consuming lane's frame can represent — not a property of the language. Two things follow:

1. operators.py is explicit that it is lane-independent: "Imported by the linopy-free lane, so it stays dependency-free." A load error here would encode one consumer's current capability into the shared language.
2. The docs hedge it: "cannot yet say". If the frame gains the ability, the rule should disappear — and a rule that is expected to be removed is a poor fit for a load error, which is a promise about what the language means.

Against that: the spec currently renders math that no lane can build, which is the same class of harm the other rules were fixed for. A reader gets a page that looks fine, and the failure surfaces far downstream in someone else's code.

The options

1. Enforce it as a load error. Consistent with the neighbouring rules, and the failure lands where the model is written. Costs lane-independence in this one spot.
2. Leave it to the consuming lane, and reword the docs so it reads as a consumer's limitation rather than a language rule — it currently sits in a list whose other members are load errors, which is what made it look enforced.
3. Enforce it as a warning rather than an error, if the package has anywhere for one to go.

I lean (2) unless the frame limitation turns out to be permanent, in which case (1). Either way the docs and the behaviour should stop disagreeing.

Version

v0.0.0-alpha.10