self(lark): compete with the wretox UI; riddle me impressed

[Jesssullivan]

Began reverse engineering the wretox 2d canvas UI this evening; this'll take some more effort than I thought.

The hero animation is rendered on a single using the plain 2D Canvas API (getContext('2d')) and requestAnimationFrame, all driven by one Astro‑bundled module: /_astro/index.astro_astro_type_script_index_0_lang.DqrPRLs3.js (~14 KB minified).

The bundle's option schema is fairly distinctive though — its config object exposes:

particles: generationType, ppm, max, maxWork, connectDistance, relSpeed, relSize, rotationSpeed, color
mouse: interactionType, connectDistMult, distRatio (this is the part driving the high‑performance pointer interaction — proximity‑weighted line linking + an attract/repel force based on interactionType)
gravity: repulsive, pulling, friction, maxVelocity (a lightweight verlet/Euler integrator: each frame applies repulsive + pulling forces scaled by Δt, clamps to maxVelocity, then damps with friction)

So, I think I can shoehorn revitalized, non-focal grounded (blobwise only) gravity vectors and 2d IO as well as the accel stack within this boundary for some jovial golfing, but tbh I had hoped this was some neat pre-existing system from which to iterate.

- HTTP requests: 29 (1 document + 3 scripts + 2 stylesheet links + 23 images + 1 fetch)
- Bytes over the wire (transfer / compressed): ~94 KB total
- Decoded payload (uncompressed): ~721 KB total, of which images are ~583 KB decoded / ~87 KB transferred, scripts are ~14 KB, CSS ~14 KB, and the HTML document itself is ~6 KB transferred / ~25 KB decoded
- Hydrated DOM: 262 elements, serialized HTML ~26.6 KB (≈30,137 chars)
- JS heap after load: ~6.33 MB used / ~8.49 MB allocated (limit ~2.1 GB)
- Timings: DOMContentLoaded ≈ 1.77 s, load ≈ 3.0 s