unify warnings/debug/thrown errors

[yamcodes]

right now we are throwing generic errors with a [ArkEnvError] prefix. we are also using a lot of console.log. consider improving this to use a centralized logger/error handler. this can be its own internal package or in the new utils package. this might already be a part of v1.

[pullfrog]

This run croaked 😵

The workflow encountered an error before any progress could be reported. Please check the link below for details.

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

[yamcodes]

This was generated by AI during triage.

Ready for human

Category: enhancement
State: ready for human

Why this isn't AFK-ready yet

Unifying logging, warnings, and thrown errors across ArkEnv touches package boundaries and runtime targets (Node, Bun, browser). The right abstraction and where it lives need a maintainer design call before an agent can safely implement it.

Context from triage

• ArkEnvError in packages/arkenv/src/core.ts currently formats validation failures with a fixed message and colored output but offers no logging/warning hook.
• Ad-hoc console.* calls are scattered through production packages:
  • packages/build/src/index.ts (watcher errors; it already accepts an optional Logger type but falls back to console.error)
  • packages/nextjs/src/config.ts and packages/nextjs/src/create-env.ts (validation failure + warnings)
  • packages/cli/src/index.ts and adapters (unhandled errors, injection failures, debug output)
  • packages/bun-plugin/src/plugin.ts (schema-load errors)
• packages/internal/ exists, and packages/arkenv/src/utils/ currently only holds small formatting helpers (indent, style-text).

Open design questions

1. Package placement: Should this be a new internal package (e.g. @arkenv/logging or @arkenv/internal/log), live in a new/expanded utils package, or be part of arkenv/core?
2. API surface: What should the logger interface be? Just error/warn/info/debug? Should it support silent mode, user-provided loggers, or environment-driven log levels?
3. Runtime constraints: How should browser-compatible packages avoid Node-only process.exit behavior (e.g. packages/nextjs/src/config.ts currently exits on validation failure)?
4. Error handling: Should ArkEnvError keep its current formatting, or should formatting move into the centralized logger so callers can control output style?
5. v1 scope: Is this work intended for v1, and if so, should it subsume or replace the existing minimal Logger type in packages/build/src/index.ts?

Suggested next step

Once the above decisions are made, this can be rewritten as an agent brief with a concrete package layout, logger interface, and migration checklist.