fix(submodule): mark bleuberi as update=none so recursive init doesn't break installs

[abhicris]

Closes #448.

Problem

`pip install` / `uv pip install` of `atroposlib` from this repo (for example as a transitive dependency of `tinker-atropos`) calls `git submodule update --recursive --init`, which currently fails:

```
fatal: Unable to checkout '...' in submodule path
'environments/community/bleuberi/bleuberi-repo'
```

The root cause is upstream: lilakk/BLEUBERI tracks `arena_analysis/arena_1k_final/` with Git LFS, and the upstream LFS budget is exhausted (`batch response: This repository exceeded its LFS budget`). The smudge filter hard-fails, taking down submodule checkout — and therefore the entire install — for every new user, regardless of whether they actually want the BLEUBERI environment. See #448 for a full reproducer.

Fix

Mark only the `bleuberi-repo` submodule with `update = none` in `.gitmodules`. `git submodule update --init --recursive` (and tooling that wraps it: uv, pip git installs, `pre-commit`'s recursive submodule init) now skip this entry by default. Users who actually want to run `bleuberi_env.py` fetch it explicitly:

```bash
git submodule update --init environments/community/bleuberi/bleuberi-repo
```

…optionally with `GIT_LFS_SKIP_SMUDGE=1` to bypass the upstream LFS issue when they don't need the eval data.

The other three submodules (`internbootcamp_lib`, `reasoning-gym`, `AI_Diplomacy`) are unaffected and keep their default behavior — none of them are LFS-bound.

Why `update = none` (vs deleting the submodule)

Keeping the entry registered preserves the pinned commit + URL, so contributors working on BLEUBERI specifically still get reproducible checkouts via the explicit init command. Deleting the submodule would lose that pinning. `update = none` is the documented git mechanism for opt-in submodules (gitmodules(5)).

Files changed

• `.gitmodules` — one-line addition (`update = none` on the bleuberi entry).
• `environments/community/bleuberi/README.md` — install section now documents the explicit submodule init step + the `GIT_LFS_SKIP_SMUDGE=1` workaround, linking lfs budget exceeded #448.
• `environments/community/bleuberi/bleuberi_env.py` — if a user imports the env without first initializing the submodule, raise a `RuntimeError` with the exact init command, instead of the current opaque `ModuleNotFoundError: No module named 'training'`.

Verification

```
$ git config -f .gitmodules --get-regexp '^submodule.environments/community/bleuberi/bleuberi-repo..*'
submodule.environments/community/bleuberi/bleuberi-repo.path environments/community/bleuberi/bleuberi-repo
submodule.environments/community/bleuberi/bleuberi-repo.url https://github.com/lilakk/BLEUBERI.git
submodule.environments/community/bleuberi/bleuberi-repo.update none
```

`git submodule update --init --recursive` from a clean clone of this branch initializes the other three submodules and does not attempt to clone `bleuberi-repo`. The explicit `git submodule update --init environments/community/bleuberi/bleuberi-repo` still works (and reproduces the upstream LFS error, which is independently addressable on the BLEUBERI side or via `GIT_LFS_SKIP_SMUDGE=1`).

`bleuberi_env.py` AST-parses; the new `RuntimeError` only fires when the submodule directory exists but is empty (the unpopulated git submodule state).