v1.2.0/#22: tools.d/ plugin scan — host-local tool extensions

Adds a directory-scan plugin mechanism to the packaged server.lua
so hosts can drop their own tools alongside the packaged generics
without forking server.lua.

Mechanism:
- After all packaged tool registrations + before transport selection,
  the server scans LMCP_TOOLS_DIR (default /opt/lmcp/tools.d on POSIX,
  %ProgramData%\lmcp\tools.d on Windows) for *.lua files.
- Each plugin file is invoked as a function receiving (server, run):
    local server, run = ...
    server:tool("my_local_tool", "...", {...}, function(a) return ... end)
- Load errors and runtime errors are reported on stderr and skipped;
  the server continues with the tools it successfully loaded.

Why:
Hosts like hertz and ampere have always carried local /opt/lmcp/server.lua
overrides containing both packaged-overlap tools (shell, read_file, …)
AND host-specific tools (fritz, ha_api, mqtt_*, lxc_exec, …). When the
override drifts, the host either loses packaged improvements (the v1.1.1
fetch/web_search regression on hertz/ampere) or accumulates hand-merged
patches that vanish on shutdown (the original symptom in issue #22).
With tools.d/, hosts drop ONLY their custom tools as plugin files; the
packaged server.lua stays canonical. apt upgrade picks up new packaged
tools automatically.

Smoke-tested:
  $ mkdir -p /tmp/probe && cat > /tmp/probe/p.lua <<E
  local server, run = ...
  server:tool("plugin_probe", "test", {type="object"},
              function() return "ok" end)
  E
  $ LMCP_TOOLS_DIR=/tmp/probe lua server.lua
  lmcp: loaded plugin /tmp/probe/p.lua
  $ curl POST tools/list → plugin_probe present in the 10 tools listed

Existing single-file server deployments (no /opt/lmcp/tools.d/) keep
working unchanged — io.popen on a non-existent directory returns nil
and the plugin loop no-ops. Backwards compatible.

Closes the structural side of #22 (the ad-hoc-override pattern); ampere
+ hertz migration to use tools.d/ for their custom tools is the operator
follow-up.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

server.lua

@@ -1066,6 +1066,46 @@ if WINDOWS then
     })
 end
 
+-- ---- host-local tool plugins (issue #22) ----
+-- Load every .lua file in LMCP_TOOLS_DIR (default /opt/lmcp/tools.d on POSIX,
+-- %ProgramData%\lmcp\tools.d on Windows). Each file is invoked as a function
+-- receiving the configured `server` instance and the `run` helper:
+--
+--     local server, run = ...
+--     server:tool("my_local_tool", "...", {...}, function(a) return run(...) end)
+--
+-- This is the standard plugin pattern (nginx conf.d/, systemd-tmpfiles.d, …).
+-- Hosts can ship their own tools alongside the packaged generics without
+-- forking the upstream server.lua.
+local plugin_dir = os.getenv("LMCP_TOOLS_DIR")
+    or (WINDOWS and (os.getenv("ProgramData") or "C:\\ProgramData") .. "\\lmcp\\tools.d"
+                 or "/opt/lmcp/tools.d")
+local list_cmd = WINDOWS
+    and ('dir /b "' .. plugin_dir .. '\\*.lua" 2>nul')
+    or  ('ls -1 "'  .. plugin_dir ..  '"/*.lua 2>/dev/null')
+local lh = io.popen(list_cmd)
+if lh then
+    for path in lh:lines() do
+        -- On Windows `dir /b` emits bare filenames; prefix the dir.
+        local full = path:match("[/\\]") and path
+                  or (plugin_dir .. (WINDOWS and "\\" or "/") .. path)
+        local chunk, err = loadfile(full)
+        if chunk then
+            local ok, perr = pcall(chunk, server, run)
+            if ok then
+                io.stderr:write("lmcp: loaded plugin " .. full .. "\n")
+            else
+                io.stderr:write("lmcp: plugin " .. full .. " errored: "
+                    .. tostring(perr) .. "\n")
+            end
+        else
+            io.stderr:write("lmcp: plugin " .. full .. " load error: "
+                .. tostring(err) .. "\n")
+        end
+    end
+    lh:close()
+end
+
 local transport = os.getenv("LMCP_TRANSPORT") or "http"
 if transport == "stdio" then
     if os.getenv("LMCP_PORT") then