Support 4-wide vector type definitions via Frontend setting

[green-real]

Summary

The embedded builtin type definitions describe vector as 3-wide unconditionally, so under a VM built with LUA_VECTOR_SIZE == 4 the analyzer is wrong: it misses the w component and rejects the fourth create argument. This PR makes the vector width a runtime choice on the Frontend so a single Analysis build can serve either 3 or 4 wide vectors.

Changes

A VectorSize enum (Three / Four, so only valid widths are representable) becomes a setting on the Frontend, mirroring SolverMode: getVectorSize() / setVectorSize() over an atomic member, defaults to Three to preserve existing behavior. Both the 3-wide and 4-wide vector definitions are compiled in and chosen at runtime when builtins are registered; the shared method list is a single definition. The width is supplied by the embedder, so the Analysis library does not depend on the VM's configuration header.

The bundled CLIs set VectorSize from the LUA_VECTOR_SIZE they were built with; other embedders (e.g. an LSP) may set it from their own config.

The default (VectorSize::Three) definition source is byte-for-byte identical to before, so existing behavior is unchanged.
The VectorSize::Four source adds exactly the read w: number component and the w: number? argument to create.