feat: merge the asobi_lua runtime into asobi (wave 1a)

[Taure]

Wave 1a of the asobi_lua merge. One-way move of the Lua runtime, bots, tests
and guides out of widgrensit/asobi_lua and into this repo. No module was
renamed - asobi_lua_* and asobi_bot_* keep their names, so game scripts
and Erlang callers are unaffected.

asobi_lua the repo is untouched, asobi_engine is untouched, nothing was
published.

What was broken / what had to change

Three things could not survive a plain file copy.

1. asobi_lua_app.erl was an application callback for an application that
no longer exists. asobi_lua_app.erl:8-19 loaded the game config and then
started asobi_lua_sup. Both had to move somewhere, and where matters:
because asobi_lua depended on asobi, it started second, so the config load
landed after every asobi_sup child was already up.

That ordering is load-bearing in a bad way. asobi_guest_reaper:start_link/0
(src/asobi_guest_reaper.erl:26) reads guest_auth and returns ignore when
it is false - and asobi_lua_config:apply_guest_auth/1
(src/lua/asobi_lua_config.erl:126) is what sets it, always too late. That is
exactly #327, filed today. This PR preserves that order rather than
accidentally fixing it: asobi_sup:init/1 gains lua_game_config_spec() and
lua_sup() as the last two children, after guest_reaper_spec(). Moving the
load earlier would silently close #327 inside a 100-file move PR, which is the
wrong place for it. Flagging for the reviewer: if you would rather this PR
fix #327 too, say so and I will hoist the load and re-run.

Failure semantics: a bad game config still aborts the boot. It now surfaces as
a supervisor failed_to_start_child instead of a bare application-start error,
so it also takes the already-started core children down with it. Still
fail-closed, but it is a change in shape - src/asobi_sup.erl:60-72.

2. Six documented operator knobs would have gone silently dead.
dev_errors, reload_mode, max_heap_words, terrain_providers,
config_watch_interval and rate_limits were read with
application:get_env(asobi_lua, ...). application:get_env/3 against an
application that is never loaded returns the default without complaint, so
after the merge every {asobi_lua, [...]} block in a self-hoster's sys.config
would quietly stop having any effect. New src/lua/asobi_lua_env.erl reads
asobi_lua first and falls back to asobi, so existing deployments keep
their exact behaviour and {asobi, ...} is the home for new config.
rate_limits is the one key both halves read; the group names are disjoint
(log/log_global vs auth/api/...), so one merged map carries both.

3. Test fixture lookup pointed at the wrong application. 18 moved test
modules resolved fixtures via code:lib_dir(asobi_lua), which now returns
{error, bad_name}. Repointed at code:lib_dir(asobi); the fixtures live at
test/fixtures/lua/ here, same relative layout.

Everything else

• src/lua/ (runtime), src/lua/bots/ (bot processes), include/asobi_lua_bots.hrl,
  test/* and test/fixtures/lua/**.
• luerl ~> 1.5 added to rebar.config deps and to applications in
  src/asobi.app.src. vsn untouched. rebar.lock picked up luerl 1.5.1;
  cowlib was already at 2.19.0 so asobi_lua's explicit cowlib pin was not needed.
• ex_doc extras gained self-hosting, security-sandbox,
  security-trust-model, security-lua-known-limitations, plus new
  Lua Runtime and Bots module groups.
• nightly.yml picks up prop_lua_bridge_input_threading and
  prop_lua_error_containment at high numtests - asobi_lua's nightly ran them,
  so dropping them would have been a silent coverage loss.

Guide reconciliation

Three filenames collided.

• guides/lua-scripting.md and guides/lua-bots.md here were stubs whose only
  content was "this lives in asobi_lua, go read it there". Replaced with the
  real content, since the thing they pointed at is now in this repo.
• guides/security-known-limitations.md is a genuine collision: this repo's is
  about core runtime limits, asobi_lua's is about the Lua sandbox. asobi_lua's
  landed as guides/security-lua-known-limitations.md, retitled
  "Known limitations (Lua sandbox)". Neither was overwritten.
• security-sandbox.md, security-trust-model.md, self-hosting.md are new.
  Fixed the cross-links: the core known-limitations page now links locally to
  security-sandbox.md instead of to a github.com/widgrensit/asobi_lua URL, and
  self-hosting's ../README.md#quickstart anchor was repointed at this README's
  #try-it-in-60-seconds.

What the tests assert

• test/asobi_sup_lua_children_tests.erl - pins the fold. asobi_lua_config
  and asobi_lua_sup are both supervised; they are the last two children in
  that order; asobi_guest_reaper starts strictly before the config load (the
  guest_reap_after never runs: reaper returns ignore before guest_auth is set #327 ordering, pinned so a later refactor cannot change it by accident); the
  asobi_lua_sup spec is type => supervisor; and asobi_lua_sup still has its
  own four children in order.
• test/asobi_lua_env_tests.erl - a legacy {asobi_lua, K} value is still
  honoured, an {asobi, K} value is read when the legacy key is unset, the
  legacy key wins when both are set, and the default / undefined come back
  when neither is.
• The 22 moved test modules and 5 moved property modules run as-is.

Verification

command	result
rebar3 fmt / rebar3 fmt --check	clean
rebar3 xref	clean
rebar3 eunit	928 tests, 0 failures (159s)
rebar3 dialyzer	clean, no warnings
rebar3 ex_doc	clean, no warnings

Not verified, honestly:

• rebar3 ct was not run - it needs Postgres. test/asobi_lua_SUITE.erl
  came across and compiles, but it has never executed in this repo. Note that
  ci.yml:48 records that an asobi_lua_SUITE.beam "removed in refactor: extract Lua scripting into asobi_lua #59" used to
  resurrect itself from a stale cache and crash CT on luerl:init/0 undef -
  that specific failure mode is gone now that luerl is a real dep, but CI is
  the first place the suite will actually run.
• Downstream breakage is guaranteed and out of scope. asobi and
  asobi_lua now both define asobi_lua_* modules. Any consumer depending on
  both - the asobi_lua repo itself, and asobi_engine - will get duplicate
  modules on the next asobi pin bump. asobi_lua's bump-asobi-pin.yml
  automates that bump, so it will fire on merge. Wave 1b needs to land close
  behind this.
• The application:set_env(asobi, ...) calls at src/lua/asobi_lua_config.erl:126
  and :434 are left exactly as they were - now internal writes rather than
  cross-application ones. Per the brief, the core-owned write path is S3.
• asobi_lua's docs/adr/0001 and 0002 were not moved - their numbers
  collide with this repo's existing docs/adr/0001 and 0002 and renumbering
  someone else's decision records is a maintainer call.
• No ADR was written for this merge. The brief calls it ADR 0008, but this
  repo's docs/adr/ stops at 0005, so I did not want to guess the number.
  Code comments reference "the asobi_lua merge" in prose instead.
• Wider docs still describe asobi_lua as a separate repo and image (README,
  guides/comparison.md, guides/exit.md, guides/glossary.md, the three
  migrate-from-*.md). Those statements are still true today - the repo and
  ghcr.io/widgrensit/asobi_lua both exist - so I left them for the wave that
  actually retires them.

One deviation from the brief

The brief said to copy asobi_lua/src/** into src/lua/ "preserving its
internal structure", which literally would have produced src/lua/lua/*.erl.
I collapsed that redundant level: the inner src/lua/ files sit directly in
src/lua/, and src/bots/ is preserved as src/lua/bots/. Trivial to undo if
you want the literal layout.

Related: #327 (not closed by this PR - the ordering it describes is deliberately
preserved here).