wrld-dev@1.0.0

The package exposes a public authentication API (`auth.user.login`, `auth.user.register`, `auth.user.get`, `auth.user.delete`, plus an `auth.system` RPC surface) wired to a Supabase client constructed from `AUTH_URL`/`AUTH_KEY` values bundled in the package's own `.env` file. In `SupaAuth/interface.js`, `createClient(supaAuth.url, supaAuth.key)` is built from `AUTH_URL=https://xyxkteprdjiyctrpbaym.supabase.co` and a hardcoded JWT, with no parameterization on the public API to override the destination. Any consumer that integrates this package to authenticate its own users will transmit those end users' email and password to the author's Supabase tenant on every `login`/`register` call — the canonical silent-relay shape, where the package's advertised functionality unconditionally exfiltrates caller-supplied data to a fixed author-controlled endpoint. Compounding the impact, the published tarball also ships two Supabase JWTs in `.env` whose decoded payload is `{"role":"service_role"}` for projects `xyxkteprdjiyctrpbaym` and `ylznhlroyioyxpasyahm`. These are full DB-admin keys that bypass row-level security; anyone who installs the package can read them from the tarball and gain admin access (read/write/delete all tables, delete arbitrary auth users) to those Supabase projects. While the leaked admin keys are primarily author self-harm, in combination with the silent relay they mean any end-user credentials collected through integrators of this package land in a Supabase tenant whose admin key is publicly recoverable from the npm artifact.