Re-vendor the canonical files from sneak/prompts at dd4027b (closes #112)

The shared files are fetched from sneak/prompts dd4027b, with this
repository's own entries after the shared content in .gitignore,
.editorconfig and .dockerignore.

Lint and tests are Dockerfile phases (golangci-lint v2.14.0, Debian Go
1.24.13) that the build stage depends on, and the Makefile targets call
the script/ entrypoints. make fmt also formats Markdown with prettier.

Fixes for the new lint findings: the auth cookie is always Secure, an
IRC connection's relay goroutine stops when the connection closes, and
repeated strings are constants. neoirc-cli treats a plain-HTTP server on
localhost or a loopback address as secure, so local use keeps its session.

Whether the 60-second test cap covers building the test phase is open
on sneak/prompts issue 113.

Model: opus-5-5

CONVENTIONS.md

@@ -1,6 +1,8 @@
 # Go HTTP Server Conventions
 
-This document defines the architectural patterns, design decisions, and conventions for building Go HTTP servers. All new projects must follow these standards.
+This document defines the architectural patterns, design decisions, and
+conventions for building Go HTTP servers. All new projects must follow these
+standards.
 
 ## Table of Contents
 
@@ -84,10 +86,11 @@ project-root/
 
 ### Key Principles
 
--   **`cmd/{appname}/`**: Only the entry point. Minimal logic, just bootstrapping.
--   **`internal/`**: All application packages. Not importable by external projects.
--   **One package per concern**: config, database, handlers, middleware, etc.
--   **Flat handler files**: One file per handler or logical group of handlers.
+- **`cmd/{appname}/`**: Only the entry point. Minimal logic, just bootstrapping.
+- **`internal/`**: All application packages. Not importable by external
+  projects.
+- **One package per concern**: config, database, handlers, middleware, etc.
+- **Flat handler files**: One file per handler or logical group of handlers.
 
 ---
 
@@ -188,7 +191,8 @@ Providers are resolved automatically by fx, but conceptually follow this order:
 2. `logger.New` - Logger (depends on Globals)
 3. `config.New` - Configuration (depends on Globals, Logger)
 4. `database.New` - Database (depends on Logger, Config)
-5. `healthcheck.New` - Health check (depends on Globals, Config, Logger, Database)
+5. `healthcheck.New` - Health check (depends on Globals, Config, Logger,
+   Database)
 6. `middleware.New` - Middleware (depends on Logger, Globals, Config)
 7. `handlers.New` - Handlers (depends on Logger, Globals, Database, Healthcheck)
 8. `server.New` - Server (depends on all above)
@@ -452,11 +456,11 @@ func New(lc fx.Lifecycle, params HandlersParams) (*Handlers, error) {
 ### Closure-Based Handler Pattern
 
 For JSON route handlers, both the request and the response structures are
-defined in the scope of the method that returns the HandlerFunc.  They can
-be called simply `Request` and `Response` or slightly more descriptive
-names.
+defined in the scope of the method that returns the HandlerFunc. They can be
+called simply `Request` and `Response` or slightly more descriptive names.
 
-All handlers return `http.HandlerFunc` using the closure pattern. This allows initialization logic to run once when the handler is created:
+All handlers return `http.HandlerFunc` using the closure pattern. This allows
+initialization logic to run once when the handler is created:
 
 ```go
 // internal/handlers/index.go
@@ -517,10 +521,11 @@ func (s *Handlers) decodeJSON(w http.ResponseWriter, r *http.Request, v interfac
 
 ### Handler Naming Convention
 
--   `HandleIndex()` - Main page
--   `HandleLoginGET()` / `HandleLoginPOST()` - Form handlers with HTTP method suffix
--   `HandleNow()` - API endpoints
--   `HandleHealthCheck()` - System endpoints
+- `HandleIndex()` - Main page
+- `HandleLoginGET()` / `HandleLoginPOST()` - Form handlers with HTTP method
+  suffix
+- `HandleNow()` - API endpoints
+- `HandleHealthCheck()` - System endpoints
 
 ---
 
@@ -741,7 +746,8 @@ func New(lc fx.Lifecycle, params ConfigParams) (*Config, error) {
 
 1. **Environment variables** (highest priority via `AutomaticEnv()`)
 2. **`.env` file** (loaded via `godotenv/autoload` import)
-3. **Config files**: `/etc/{appname}/{appname}.yaml`, `~/.config/{appname}/{appname}.yaml`
+3. **Config files**: `/etc/{appname}/{appname}.yaml`,
+   `~/.config/{appname}/{appname}.yaml`
 4. **Defaults** (lowest priority)
 
 ### Environment Loading