fix(cli): raise the VM's step budget for lex-code's own entry points

[alpibrupa]

Summary

• The lex VM's default step limit (10,000,000) is a DoS guard for untrusted sandboxed snippets (`lex run --help`). lex-code's own process — the TUI, one-shot mode, the eval harness — is trusted, long-running code, not that.
• Reproduced live: a real multi-file package build crashed outright with a step-limit-exceeded panic partway through, independent of the two other quadratic bugs fixed today (lex-schema#36, and this repo's own fix(session): per-turn history check is O(1), not O(n) per turn #136) — an ordinary verbose turn from a thinking-mode model was enough on its own to cross the budget.
• `lex run --max-steps 20000000000` already exists for exactly this; `src/index_build.lex`'s own README section already needed it for its long-running batch job — same precedent, just not applied to the TUI/agent-loop entry point.
• `bin/lex-code` now sets the same value by default (overridable via `LEX_CODE_MAX_STEPS`, matching the existing `LEX_CODE_EFFECTS` pattern), `scripts/eval.sh`'s harness invocation gets the same flag, and the README's literal `lex run` examples (TUI entry point, MCP/A2A/web servers, ACP server) are updated to match. `bin/lex-code`'s own comment carries the full explanation, and the Quickstart section now points there instead of duplicating it.

Test plan

• Full repo sweep (`lex check` over every tracked `src/` file), `lex fmt --check src/`, `lex test` (4/4), `lex doc-sync --check` — all clean (this PR touches no `.lex` source, just the wrapper script, the eval harness script, and docs)
• Smoke-tested `bin/lex-code` directly against a real one-shot task with the new flag in place
• Confirmed the flag actually eliminates the underlying panic class: reproduced a step-limit-exceeded panic on a synthetic escape-dense payload, then confirmed `--max-steps 0` (and separately, the `20000000000` value used here) parses the identical payload cleanly with no panic

🤖 Generated with Claude Code