Typed array performance

Litegraph makes some good use of typed arrays, however there are growing drawbacks and limitations.

1. Typescript does not fully support typed arrays
- Despite being fixed-length by design, it cannot be used in type inference
- Tuples become painful to manage
- Narrowing types sometimes requires _runtime_ checks, potentially causing performance loss rather than gain
2. Many third party libraries do not support them
- Adds complexity to consumer code
- Limits flexibility

This is resulting in needless abstractions and extraneous type-checking.

Suggestion is to convert internal use of `Float32Array` to `number[]`, where appropriate. e.g. `pos`, `size`, and other places. In the render pass, arrays are used as fast memory buffers, and this usage is probably fine as is (or converted to `Float64Array`).

Impact / checks:
- Precision (`number` not being 32bit)
- Refactoring
- Downstream consumers relying on `Float32Array` (it is far more common for consumers to replace the initial `Float32Array` properties with `number[]`)
- Over/underflow behaviour
- Performance (likely negligible on modern engines and hardware - should be proactively tested in this case)

The issue names internal Float32Array uses such as `pos` and `size`, while retaining render-pass arrays as a possible exception. Start by locating those uses and the related downstream-facing properties, then check precision, overflow behavior, consumer compatibility, and performance; done means an agreed conversion scope is implemented and proactively tested.

Written by the indexing model from the issue text.