Add an ADR log #210

Context

OpenRange has accumulated several non-obvious design decisions:

• Why a Pack ABC instead of subclassing a base "Environment" class
• Why admission (feasibility check) BEFORE the agent runs, not
  validate-as-you-go
• Why no Gym step API — every domain exposes its own surface
• Why procedural sampling + LLM enrichment instead of LLM-only
  generation
• Why entry-point discovery for packs / builders / NPCs

The reasoning behind each is captured (sometimes) in commit messages
or PR descriptions. That's fine for archeology and not great for
"new contributor wants to understand WHY before they argue with the
shape."

What this issue tracks

Add an Architecture Decisions Log — a docs/adr/ directory with
one short markdown file per decision. The standard "ADR" format is
fine:

## Status
Accepted | Superseded by N

## Context
What problem were we solving?

## Decision
What we did.

## Consequences
What this enables / forbids / makes harder.

One file per major decision, kept short (a page max), linked from
README and the relevant code areas.

Why it matters

Two contributor-facing wins:

1. Onboarding: a new contributor reading the codebase encounters
   the Pack ABC and asks "why isn't this a base class with
   inheritance?" — they read docs/adr/0001-pack-abc.md and either
   agree or argue from informed ground. Either way: faster.
2. Avoiding regressions: when someone proposes a change that
   conflicts with a load-bearing design choice, the ADR is the
   thing reviewers can point at.

Where to start

• Pick the 5-7 biggest decisions to document first. Suggested seed
  list:
  • Pack ABC vs subclassing
  • Admit-before-episode (feasibility check on the realized world)
  • No Gym step API
  • Procedural + LLM split (vs LLM-only or procedural-only)
  • Entry-point discovery for packs / builders / NPCs
  • Domain-agnostic interface mapping shape (HTTP backing's
    {base_url, http_get, http_get_json} → other backings ship
    their own)
• For each: read the relevant code + the commit messages that landed
  it + the migration plan if you have access.
• Format: docs/adr/NNNN-short-slug.md.

Acceptance

• docs/adr/ exists with at least 5 ADRs covering the seed list.
• Linked from README under "Start with."
• Format is consistent across all of them.

Notes

ADRs aren't change requests. They document what's already decided.
If you find yourself wanting to argue with the decision while
writing the ADR, capture the reasoning that led to the current
state honestly, then open a separate issue if you think the
decision should be revisited.

Great help wanted task that doubles as a deep read of the
codebase for the writer.