Add scriptable View Type

[JeroenDeDauw]

Drafted by @JeroenDeDauw with Claude Code, after a back-and-forth to capture design discussions that aren't yet recorded in an issue, ADR, or planning doc.
Context: ADR 018 (Views), the View Type plugin system, the existing mw.neowiki Lua API, and prior design discussions.
_{Written by Claude Code, Opus 4.7}

Goal

Provide a built-in View Type that delegates rendering to a Lua module, so template authors can produce arbitrary output for a Subject (or set of Subjects) without waiting for a new built-in View Type to be added to NeoWiki core.

This is a plug-in on the View Type plugin system (#659) — i.e. it's how we eat our own dog food on the plug-in API, and it's the escape hatch that makes adding new built-in View Types less urgent.

Why

• Unblocks dashboards and custom layouts. End-user use cases (HW's QM dashboard, ad-hoc Subject renderings) currently require either waiting for a dedicated View Type or working around the system entirely. A scriptable View Type lets these be authored in-wiki.
• Composes with the rest of the Lua API. A scripted view can internally use nw.getMainSubject(), nw.query() (Add nw.query() to mw.neowiki Lua API #736), and nw.getSchema() (Add nw.getSchema() to mw.neowiki Lua API #737) to render dashboards over query results, not just single Subjects.
• Stress-tests the View Type plug-in API. If the plug-in surface is rich enough to express "hand the data to Lua and let it render," it's likely rich enough for most third-party View Types.

In scope

• A View Type that, when used by a Layout, dispatches rendering to a configured Lua module.
• Wiring through the existing {{#view}} invocation path so referencing a Layout that uses this View Type Just Works.
• Sensible behaviour when the Lua module is missing, errors out, or returns something unexpected.
• Tests covering the happy path and the failure modes.

Out of scope

• Built-in table / list / factbox View Types — separate issues.
• A visual builder for scripted views.
• Sandboxing concerns beyond what MediaWiki's Scribunto already provides.

Things to figure out (not prescriptions)

• What the Lua entry point receives. Options include: the Subject data as a table, the Layout's settings, the Display Rules (so Lua can honour them), or some combination. There's a tradeoff between giving Lua everything and keeping the API small.
• How the Lua module is referenced from the Layout. A module name is the obvious starting point; whether to also pin a function name or rely on a convention is open.
• Interaction with Display Rules. Either Lua sees the raw Subject and decides what to render, or Display Rules pre-filter what reaches Lua. Both have merit.
• Failure modes. Missing module / runtime error / non-string return — how visible should the failure be? Inline error box vs. silent fallback to default rendering.
• Multi-Subject rendering. Whether this View Type only renders a single Subject (the View's target) or can also render lists / query results is a design choice; the latter is more powerful but enlarges the contract.

Related

• View: View Type plugin system #659 — View Type plug-in system (closed; this issue is the first non-trivial consumer)
• Add nw.query() to mw.neowiki Lua API #736 — nw.query() — likely used inside scripted views
• Add nw.getSchema() to mw.neowiki Lua API #737 — nw.getSchema() — likely used inside scripted views
• #view parser function: named arguments, only one positional #739 — #view parser function ergonomics