fix(ir): vector lane store resolves lane element type [F0.5]

Writing a Vector lane (`v.x = …`, `.y/.z/.w` + colour aliases) panicked
with "unresolved type reached LLVM emission". The store path had no
vector branch: a `.field_access` target on a Vector fell through to
struct-field lookup, matched nothing, left `field_ty = .unresolved`, and
built a `ptrTo(.unresolved)` that tripped the LLVM emission guard. The
read path resolved the lane fine — the two had diverged (issue-0083
two-resolver class).

Extract a shared `Lowering.vectorLaneIndex` resolver and route BOTH paths
through it. The read path (`lowerFieldAccessOnType`) delegates to it,
dropping its silent `else 0` fallback. A new vector branch in
`lowerAssignment` GEPs a typed pointer to the lane (`structGepTyped`) and
stores via `storeOrCompound` (plain + compound). `emitStructGep` now
addresses a vector base type with a `[0, lane]` GEP. A non-lane field now
reports field-not-found on both paths instead of silent-lane-0 / panic.

Regression: examples/1506-vectors-lane-store.sx (panicked pre-fix, now
reads back written values) + a vectorLaneIndex unit test. Resolves issue
0086; spec documents element assignment.

specs.md

@@ -1170,6 +1170,13 @@ v.x     // first element
 v.z     // third element
 ```
 
+**Element assignment**: the same lane names are assignable l-values; plain and
+compound assignment write a single component in place.
+```sx
+v.x = 1.0;    // write the first lane
+v.y += 2.0;   // compound assignment to a lane
+```
+
 **Index access**: `v[i]` extracts by index.
 ```sx
 v[0]    // first element