feat: say what wikven does about Lua, and stop guessing at it

[lens0021]

Scribunto is ordinary equipment on a MediaWiki wiki, and wikven's two products disagreed about it silently. Measured on a bake of one page invoking one module, every one of these exited 0:

Scribunto	module file	rendered	module in the export
listed, engine present	Module:Example	Lua says hello	no
not listed	Module:Example	{{#invoke:Greet|hello}}	no, the file was ignored entirely
not listed	Module:Example.wikitext	{{#invoke:Greet|hello}}	yes, as Module%3AGreet.html

Three of those four ways to have a Lua module published a site with braces where the page meant to say something, and one exported the module's own Lua source as a page. Nothing said a word. #465 guessed this would show up as "red module errors"; raw wikitext is worse, because it looks like someone's typo rather than a missing engine.

The answer, per the decision on #465

Supported under the Docker image, not in the standalone binary. That is not a preference. static-php-cli, which builds the binary's PHP, offers no Lua extension among the ~130 it supports, and Scribunto's other engine shells out to a lua program that a single executable has no way to ship. Checked against upstream's own list rather than assumed.

One refusal and one warning

includes/Scribunto.php holds both rules; build.php runs them before clearOutputDirectory, so a site that is refused still has its last bake on disk.

• Scribunto where no engine can run it → refused, naming the product that cannot. The site asked for Lua in so many words and this build cannot give it; publishing braces instead is worse than being told no.
• Module: files with no Scribunto in extensions → warned about, naming the files, and the bake goes on. The site never asked for Lua, and what those files are is a guess read off a name: they may be on their way in, on their way out, or kept for something else. Refusing there decides for the site, which is not this build's call. So it says what it sees — the invocations stay in the pages as their own source text, and a module named with the .wikitext marker is exported as a page — and lets the bake finish.

A site with no Lua at all is told nothing, which matters: that is most sites, and the binary is what they are pointed at.

Verified by baking, not by reading. The refusal:

=== scribunto-with-engine
  bake exit: 0
  index.html: present
=== no-lua-at-all
  bake exit: 0
  index.html: present

The engine-missing case was tested by mounting an empty ini over the image's docker-php-ext-luasandbox.ini, which is as close to the binary as this machine gets:

bake exit: 1
Wikven: this site lists Scribunto and no Lua engine is available here. The Docker image has one;
the standalone binary has none, so it cannot bake a site that uses Lua modules. ...

That run also proves the image has no lua on PATH: engine detection tries luasandbox, then a configured luaPath, then lua5.1/lua on PATH, and it still fired. A hand-rolled install with the standalone engine is therefore not refused for no reason.

The modules-without-Scribunto case was baked while it was still a refusal (bake exit: 1, no index.html, message naming Module:Greet). Since it became a warning it is covered by the unit suite and not by a fresh bake — the bake host here has no Docker. What changed is which of the two functions produces the string and whether build.php calls fatalError() or output() with it; the message and the file detection are the same code that bake exercised.

The page

Lua modules, between Extensions and JavaScript, in English and Korean. How to enable it, why a module file carries no .wikitext marker (its content model is Lua), what reaches the published site, and what each of the two mismatches does.

It demonstrates itself: it shows Module:Example in full, invokes it, and prints the answer. The module returns the title of the page it ran on and no prose, because a module's return value is not a translation unit and would reach a reader of any language in whatever language it was written in — the sentence around it carries the words instead.

Standalone binary gains a "What it cannot do" section: it claimed its output was the same as the image's, which is now known to be false in exactly one way. Extensions points at the new page. Development documents the new build step.

What holds it

smoke.yml asserts the module's answer is in the exported page in both languages, and that nothing named Module* was exported.

It deliberately does not assert the absence of {{#invoke: in the output. The new page documents the syntax inside <syntaxhighlight> and so contains it legitimately — confirmed in the bake, three occurrences. The positive assertion is the one that tells rendering from leaking.

Ran locally against a real bake of this site:

ok    dist/Lua_modules.html carries the module's answer
ok    dist/Lua_modules/ko.html carries it in Korean
ok    the module is not a page of the site
ok    414 language-bar entries, as the source predicts

Two bakes byte-identical, so a module costs no reproducibility. The prevnext chain reads Skins → Extensions → Lua modules → JavaScript → Searching, and shows Lua 모듈 in Korean, which incidentally exercises #466 on a brand-new page. translate check reports everything up to date.

A consequence worth stating plainly

This documentation site now has a Lua module, so the standalone binary cannot bake it. Nothing in CI notices, because nothing bakes anything with the binary: binary.yml builds it and runs ./wikven version. That gap is real, it is not this change's to close, and it is worth its own issue.

Closes #465.