Add BADCODE env/data-dir aliases to avoid upstream T3 Code conflicts

[badcuban]

Priority: P2 (local-conflict cleanup; not a release blocker)

Current direction

The goal is not a broad public-product migration. The goal is to let BadCode and upstream T3 Code coexist safely on the same Windows machine.

Prefer additive aliases and explicit precedence over automatic migration.

Narrow scope

• Add or design BADCODE_* env vars where BadCode-specific config matters.
• Keep T3CODE_* compatibility aliases where existing scripts/users may depend on them.
• Define clear precedence when both BadCode and T3 Code variables are present.
• Avoid automatic migration from ~/.t3 unless it is opt-in or backed by a very clear rollback path.
• Document how to run BadCode without colliding with upstream T3 Code user data.

Acceptance criteria

• Define the small set of BADCODE_* env vars needed for local use.
• Define precedence between BADCODE_* and legacy T3CODE_* variables.
• Decide whether BadCode should default to a distinct data directory or only use one when configured.
• Add compatibility tests for env-var precedence and legacy fallback.
• Document the no-surprise migration behavior.

[badcuban]

Diagnostics follow-up from May 26, 2026:

The active server traces still live under C:\Users\Will\.t3\userdata\logs\server.trace.ndjson*, and desktop traces are under C:\Users\Will\.t3\userdata\logs\desktop.trace.ndjson*.

So the BadCode app is already branded in the UI, but the backend diagnostics/data home is still the legacy .t3 location. That should be included in the data-dir migration and compatibility plan.

[badcuban]

Phase 1 shipped in main and nightly v0.0.18-nightly.20260601.47. Completed: BADCODE_* aliases with BADCODE precedence, legacy T3CODE_* fallback, default ~/.badcode data root, safe no-overwrite ~/.t3code -> ~/.badcode desktop migration, compatibility coverage, and docs for the migration/alias behavior.