Restructure into a single glemy package with 4 target modules (io, pe, cs, render), rooted at the repo root

Context

The project started as a `physics_engine` Gleam package nested inside the `glemy` repo root. The user asked for a formal 4-module architecture matching the game's actual subsystems, at the repo root directly.

Options considered

Four separate Gleam packages (one per subsystem) — rejected

Not what was asked ("four distinct modules", not "four packages"); Gleam has no first-class multi-package workspace concept that would make this pay for itself here.

One package, four top-level hub modules (glemy/io, glemy/pe, glemy/cs, glemy/render) each with a same-named subdirectory for real implementation — chosen

Matches Gleam's own `gleam new` convention (top-level <package>.gleam + <package>/ subdirectory) applied per-subsystem; keeps one dependency graph, one test run, one build.

Decision

Moved the project so the repo root is the Gleam project root (package name "glemy"), with src/glemy/{io,pe,cs,render}.gleam as hub files and same-named subdirectories for implementation. JS-only subsystems (cs, render, later io) are gated with @target(javascript); pe stays dual-target.

Verification

gleam build/gleam test passed on both targets after the move; confirmed empirically that no top-level src/glemy.gleam entrypoint is required (only test/glemy_test.gleam calling gleeunit.main() is).

Consequences

Git history was reset at the new root (the prior nested repo's 2 commits were deliberately dropped, with the user's explicit confirmation, rather than rewritten/preserved) -- a one-time, disclosed loss, not an ongoing constraint.

References

• docs/development-plan.md