Add Lua-ported s6/s6-rc service definitions

Ports the community s6/s6-rc service catalog (early-boot mounts, udev,
dbus, session/power, networking, display managers, peripheral daemons)
to Lua-based service definitions.

- src/lua/s6lua.lua: shared helper library (exec, logging, fstab
  parsing, oneshot shell runner, readiness notification)
- src/native/s6exec.c: minimal execvp() binding so longrun `run`
  scripts can replace their own process image with the real daemon,
  since stock Lua has no exec() and os.execute("exec ...") does not
  solve it (the interpreter stays alive as an unsupervised parent)
- tools/catalog.lua + gen-services.lua: table-driven generator for
  the structurally identical -srv/-log daemon pairs and agetty ttys
- tools/lint.lua, check-syntax.ps1, set-exec-bits.ps1: local
  verification (no live s6/Linux target available this session)
- services/: 50 service directories (14 early-boot oneshots, 12
  daemon srv/log pairs, 6 agetty ttys, boot/mount/setup/ttys/
  graphical/default bundles)

Authored and syntax/structurally validated only. Native module is
unbuilt and daemon flags are unverified against Artix's real catalog
(gitea was unreachable during research) -- see docs/CONVENTIONS.md.

docs/CONVENTIONS.md

@@ -0,0 +1,62 @@
+# Conventions
+
+## Lua version target
+
+Author against a subset valid under **both Lua 5.4 and 5.5**: Arch/Artix currently package Lua
+5.4, while this repo is authored/syntax-checked locally with `lua55`. Avoid 5.5-only stdlib
+additions. `docs/CONVENTIONS.md` (this file) is the one place a Windows-side checker and a
+Linux-side interpreter could silently diverge — if you're unsure whether something is 5.4-safe,
+don't use it.
+
+## Naming
+
+Service directories under `services/` follow Artix's own `s6-scripts` catalog convention:
+
+- A daemon's directory is named `<name>-srv` (e.g. `dbus-srv`).
+- Its logger is named `<name>-log` (e.g. `dbus-log`), wired via `producer-for`/`consumer-for`.
+- Logs land in `/var/log/<name>` (not `/var/log/<name>-srv`).
+- Early-boot oneshots (category 1) and one-off oneshots (`coldplug`, `net-lo`, etc.) are named
+  after the action they perform, no suffix (e.g. `mount-cgroups`, `hostname`).
+- Bundles are named after the target they represent (`boot`, `mount`, `setup`, `ttys`,
+  `graphical`, `default`), not suffixed.
+
+## Adding a new `-srv`/`-log` daemon pair
+
+Don't hand-author a new service directory pair. Add a row to `tools/catalog.lua` and rerun:
+
+```
+lua55 tools/gen-services.lua
+```
+
+This regenerates every entry in the catalog (idempotent — safe to rerun after editing one row).
+
+## Swapping the default display manager
+
+`services/default/contents.d/` currently includes `sddm-srv`/`sddm-log` (Artix's own flagship
+display manager). To switch to GDM or LightDM, remove the `sddm-*` entries from
+`services/default/contents.d/` and add `gdm-srv`/`gdm-log` or `lightdm-srv`/`lightdm-log` instead
+— all three are already generated and ready to enable.
+
+## Exec strategy
+
+- `longrun` `run` scripts **must** end with `s6.exec({...})` (from `src/lua/s6lua.lua`, backed by
+  the native `s6exec.so` module) as their last statement. This is what makes the supervised
+  process the real daemon rather than a lingering Lua interpreter — see the root README and the
+  plan history for why `os.execute("exec ...")` does not work here.
+- `oneshot` `up`/`down` scripts and longrun `finish` scripts do **not** need `s6.exec` — they run
+  to completion and exit, so `s6.run`/`os.execute` is safe and preferred (simpler, no native
+  dependency).
+
+## Git executable bit
+
+Windows checkouts don't set the tree's executable-bit metadata on `git add`. Run
+`tools/set-exec-bits.ps1` before committing any new `run`/`up`/`down`/`finish`/`reload`/`check`
+file — the syntax and lint checks won't catch a missing exec bit, but `s6-supervise` will fail
+silently on the real target.
+
+## Known unverified gaps
+
+Artix's `s6-scripts` gitea repo blocked automated fetches during research, so the daemon
+argv/flags in `tools/catalog.lua` (chronyd, bluetoothd, acpid, cupsd in particular) are
+reconstructed from each daemon's documented foreground-mode flag rather than confirmed
+byte-for-byte against a reference script. Spot-check before relying on this in production.