chore: retire asobi_lua to a Docker alias for asobi

[Taure]

Integration plan items 1a.3 (keep the Docker image publishing) and 1a.4
(close the tracker), plus the urgent pin-bump stop.

Blocks merge - four commits are not upstream yet

asobi's merge snapshot (widgrensit/asobi@733cec4) corresponds to this repo at
b01c5dc (#124), verified by byte-comparing every shared module. Four commits
landed here after that point and are not in asobi/src/lua:

Commit	PR	What
4b4bf8e	#132	game-declared registration mode via a config.lua global
3354e5e	#133	real-Postgres CT coverage for the game.storage.* write path
af391ff	#131	atomize spawn-template base_state and zone.spawn override keys
1bc28be	#134	validate game.broadcast event names for immediate script feedback

Merging this PR before those are ported would regress the published image -
ghcr.io/widgrensit/asobi_lua:latest would go from carrying them to not carrying
them. Tracked as widgrensit/asobi#346. Port first, bump the asobi tag in
rebar.config to the release that contains them, then merge this.

There is also uncommitted work in the primary checkout on
fix/storage-update-badarg-296 touching src/lua/asobi_lua_api.erl and
test/asobi_lua_api_tests.erl. That needs to be reopened against asobi.

Urgent: the daily pin bump is deleted

.github/workflows/bump-asobi-pin.yml ran on a 30 4 * * * cron and moved the
asobi pin in rebar.lock to whatever main was, unattended. asobi main now
contains this repo's runtime.

Verified: 16 of this repo's 17 modules are defined by both applications. Only
asobi_lua_app.erl is unique.

asobi_bot                asobi_lua_dev_errors     asobi_lua_phases
asobi_bot_spawner        asobi_lua_game_error     asobi_lua_reload
asobi_bot_sup            asobi_lua_loader         asobi_lua_sup
asobi_lua_api            asobi_lua_match          asobi_lua_validate
asobi_lua_config         asobi_lua_match_shared   asobi_lua_world
asobi_lua_config_watcher

This is not a subtle failure. Simulating the next nightly run on origin/main
(rebar3 upgrade asobi then rebar3 as prod release):

===> Assembling release asobi_lua-0.2.5...
===> Error generating release:
Duplicated modules:
	asobi_lua_game_error specified in asobi and asobi_lua
	asobi_lua_dev_errors specified in asobi and asobi_lua

relx refuses to assemble. The bump PR would have opened, CI would have gone red,
and any Docker publish from a merged bump would have failed - leaving the image
stuck at whatever was last pushed with no way to rebuild it.

Deleted rather than paused: item 1a.5 retires it anyway, and after this PR there
is no local source for a pin to be compatible with. Refreshing the alias is now
a deliberate act - set the tag in rebar.config, rebar3 upgrade asobi, PR the
lock.

.github/workflows/nightly.yml goes too: its only job ran
prop_lua_bridge_input_threading and prop_lua_error_containment, which are
deleted here and live in asobi. Left alone it would have failed every night and
auto-opened a nightly-regression issue each time.

1a.3: the image keeps publishing, but stops building from local source

The plan says keep it building as an alias or deprecated tag stream and do not
rename it out from under people running it. Three options:

1. Keep building from local source, pin frozen pre-merge. No duplicate-module
   build, but the image is frozen on pre-merge asobi forever. asobi publishes no
   Docker image of its own, so this is the only maintained self-host image there
   is - freezing it means self-hosters never get another fix. Rejected.
2. Stop publishing. Breaks everyone running it. The plan explicitly forbids it.
3. Keep publishing; stop building from local source. Chosen.

asobi_lua the OTP application had exactly one thing left to do, and asobi
already does it: asobi_lua_app:start/2 loaded the game config and started
asobi_lua_sup, and asobi_sup:init/1 now has lua_game_config_spec() and
lua_sup() as its last two children, in that order, deliberately preserving the
old boot sequence. So the release drops to [asobi, sasl] and the application
disappears with nothing lost.

What a user sees is unchanged:

	Before	After
Image	ghcr.io/widgrensit/asobi_lua	same
Tags	latest, vX.Y.Z, X.Y, sha-…	same
Entrypoint	bin/asobi_lua foreground	same
Node name	-sname asobi_lua	same
Port, volume, env vars	8084, /app/game, ASOBI_*	same

Verified locally - rebar3 as prod release assembles, bin/asobi_lua is there,
lib/ contains asobi-0.51.4 and no asobi_lua-*, and all 16 modules ship from
asobi's ebin exactly once.

docker-publish.yml's staleness gate is kept and repointed: it still fails a
publish when the pin is behind the latest asobi release, which is now the only
signal that the alias has drifted. CI is a release build plus an explicit
duplicate-module assertion, so this failure mode can never come back silently.

1a.4: tracker closed to new issues, history kept

hasIssuesEnabled is left ON - turning it off hides the history the plan wants
kept. Instead .github/ISSUE_TEMPLATE/config.yml sets blank_issues_enabled: false with contact links to asobi's issues, asobi's security advisories, and
Discord. "New issue" now offers those three and no way to file here. Existing
issues stay open, readable and searchable.

Deprecation notices at the top of README.md (runtime moved, Lua game code
unaffected, Docker image unaffected, where to file), AGENTS.md (do not add
code here) and SECURITY.md (report against asobi).

Issue #130 does not need migrating. It asked to add
repository_dispatch: [asobi-released] to bump-asobi-pin.yml so releases
reached this repo faster. That workflow is now deleted and the repo it was
speeding up has no source to update. It should be closed as obsolete, not moved.

The asobi-side dispatch that needs removing (not done here - different repo)

widgrensit/asobi#315 shipped a notify-asobi-lua job in
.github/workflows/release.yml that runs
scripts/dispatch-asobi-lua-pin-bump.sh after every tagged release, firing
repository_dispatch (event_type: asobi-released) at this repo.

It is inert today only because bump-asobi-pin.yml never declared the
repository_dispatch trigger, so the event is accepted and dropped. With that
workflow deleted it stays inert permanently, but it should be removed on the
asobi side along with scripts/dispatch-asobi-lua-pin-bump.sh, its test in
scripts/test/, and the ASOBI_LUA_DISPATCH_TOKEN secret if it was ever added.
Not touched here.

Deliberately not done

• guides/ is kept. Guide consolidation is plan item 1a.2, not this one. asobi
  already has all six; lua-scripting.md, security-sandbox.md and
  security-trust-model.md are byte-identical, and asobi's lua-bots.md,
  security-known-limitations.md and self-hosting.md differ - 1a.2 should
  confirm nothing was lost before these are deleted.
• docs/adr/ is kept. ADRs 0001 and 0002 are referenced from asobi.
• Plan item 1a.5 (asobi_engine) needs nothing: it already dropped asobi_lua
  from rebar.config and its release list.
• Never on Hex (hex.pm/api/packages/asobi_lua is a 404), so there is no package
  to deprecate.