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.

examples/expected/1506-vectors-lane-store.exit

@@ -0,0 +1 @@
+0

examples/expected/1506-vectors-lane-store.stderr

@@ -0,0 +1 @@
+

examples/expected/1506-vectors-lane-store.stdout

@@ -0,0 +1,7 @@
+x=1.000000
+y=2.000000
+z=3.000000
+w=4.000000
+u=10.000000 20.000000 30.000000 40.000000
+col=0.500000 0.250000 0.125000
+col2=1.000000 1.000000