Expose lush global as a standard library (issue #26)

Register luaopen_lush() in stdlibs so the lush table is available as a
global. Users can now extend the shell by adding functions to
lush.builtins. The OP_LUSH VM access via integer keys is preserved.

issues/26-shell-abbreviations-and-user-builtins.md

@@ -1,6 +1,6 @@
 # 26 — Shell abbreviations and user-extensible builtins
 
-**Status:** open
+**Status:** done
 
 ## Problem
 
@@ -60,6 +60,15 @@ This gives power users access to the shell primitives directly, which is useful
 
 Option B: Expose only `lush.builtins` — safer, sufficient for the abbreviation use case.
 
+Consider the clarity of these endpoints. Would an alternative naming scheme be clearer? i.e.
+```lua
+lush.commands    -- cd, exec, umask, user additions
+lush.run         -- __command (backtick execution)
+lush.interactive -- __interactive (! execution) -- is there an idiotmatic name for this?
+lush.getenv      -- __getenv ($VAR read)
+lush.setenv      -- __setenv ($VAR write)
+```
+
 ### Relationship to f88b1795
 
 That commit deliberately hid these from `_G` to avoid polluting the namespace. Exposing a single `lush` global is a middle ground: one clean entry point instead of scattered `__double_underscore` globals, and users can only extend via a structured API rather than accidentally shadowing internals.