feat(mcp): initial implementation — MCP server, framework indexer, 10 tools, 8 validation rules (v0.1.0)

Introduces code.nochebuena.dev/einherjar/mcp — the Einherjar Model Context Protocol
server. A remote, streamable-HTTP service that teaches AI assistants about every
other module of the framework: which package exposes which type, what each module
guarantees through its compliance tests, the canonical wiring shape for a service,
and whether a Go snippet follows the conventions. Indexes the framework on disk at
build time and ships a self-contained binary via go:embed; imports nothing from
other einherjar/* modules at compile time.

server (cmd/server):
- Streamable-HTTP MCP server built on github.com/modelcontextprotocol/go-sdk v1.0.0
- mcp.NewServer + mcp.NewStreamableHTTPHandler, served via net/http on EINHERJAR_MCP_ADDR
  (default :8080) and EINHERJAR_MCP_PATH (default /mcp)
- /healthz liveness endpoint; structured JSON logging via log/slog
- Loads the embedded data/index.json once at startup; in-memory for the process lifetime

indexer (cmd/indexer):
- Walks an Einherjar repository checkout (default ../), parses every sibling
  module's go.mod, README.md, CHANGELOG.md, docs/adr/ADR-*.md, doc.go package
  comments, every exported type/interface/func/method/const/var (via go/doc on
  go/parser ASTs), and compliance_test.go
- Captures module dependency edges by regex over each go.mod's require lines
  (einherjar/* paths only; self-reference filtered)
- Appends a synthetic "wire" module documenting canonical application wiring
  conventions, authored at internal/index/builtins/README.md and embedded via
  go:embed; participates in list_modules / get_module / get_example like a real module

internal/index:
- Schema einherjar.mcp/index/v1; types: Index, Module, SubPackage, Symbol, ADR,
  Example, Compliance, InterfaceAssert, ComplianceTest
- Build(repoRoot) → *Index walks the repo; BuildBuiltins() returns the synthetic
  wire module from the embedded markdown
- Load([]byte) → *Index validates the schema version on read
- FindModule, SearchSymbols helpers used by tools

internal/tools (10 tools):
- list_modules — enumerate every module with purpose + sub-packages
- get_module — package doc, dependencies, sub-packages, key symbols, ADRs,
  compliance counts; optional embedded README
- search_symbols — full-text across name, doc, sub-package, module; filterable by
  module and kind
- get_symbol — full signature, doc comment, source file:line for one symbol
- list_adrs — list ADRs across the framework or within one module
- get_adr — fetch one ADR's markdown body
- get_example — canonical usage snippets extracted from module READMEs and from
  the synthetic wire conventions
- get_compliance — interface assertions (var _ Iface = impl) and structural test
  names from a module's compliance_test.go
- get_changelog — full CHANGELOG.md markdown for one module
- validate_snippet — pattern-match a Go snippet against framework conventions

internal/rules (8 rules, registered via init() against a single registered slice):
- launcher.missing-run — launcher constructed but Run() never called
- launcher.no-components — launcher.New() called without any .Append(...)
- launcher.run-error-discarded — lc.Run() invoked as an ExprStmt (return ignored)
- logz.direct-env-read — os.Getenv("EINHERJAR_LOG_*") bypassing logz config
- web.server-not-appended — web/server constructed but not added to the launcher
- wire.hook-bad-signature — with<Feature>(...) first param is not launcher.Launcher
- wire.hook-outside-beforestart — repo/service/handler construction or route
  registration at the top level of a hook (outside lc.BeforeStart)
- wire.route-specific-after-param — /users/{id} registered before a sibling
  /users/me of the same length and method (chi would shadow the literal route)

Synthetic wire module (internal/index/builtins/README.md):
- Project layout (cmd/<app>/main.go + internal/wire/*.go + per-feature domain dirs)
- Canonical Run() shape: config → logger → infra (db, cache, pool, mc, srv) → cross-
  cutting (validator, permission provider) → launcher.New → lc.Append(infra...) →
  withMigrations / withSuperAdminSeed / withHealth / withFeature hooks → return lc.Run()
- Canonical with<Feature> hook shape: signature (launcher.Launcher first, server.Server
  second, deps last), single lc.BeforeStart closure containing all construction +
  route registration
- chi route ordering, srv.With(authz(...)) authorization, middleware helpers
  (authz / skipPublicPaths / skipMethodPath), tokenSignerAdapter pattern showing
  that the framework exposes Signer.Sign as a primitive and the application owns
  the access/refresh response shape

Packaging:
- Multi-stage Dockerfile that builds from the einherjar repository root
  (docker build -f mcp/Dockerfile .) so cmd/indexer can walk every sibling module
  at image-build time; runtime layer is gcr.io/distroless/static-debian12:nonroot
- 86-byte placeholder data/index.json committed once with `git add -f`; subsequent
  indexer runs overwrite it locally but the file is .gitignored
- .gitea/CODEOWNERS and pull_request_template.md mirror the sibling layout

Design notes:
- mcp depends on nothing in einherjar/* — it reads the framework via the filesystem
  at index time. This keeps mcp outside the framework dependency graph and lets it
  index any version of einherjar without versioning itself in lock-step.
- All structured-output tool responses initialise empty slices ([]Type{}) rather
  than relying on Go's nil-marshals-to-null default, so the SDK's JSON-schema
  output validator never rejects a tools/call result.

internal/index/builtins.go

@@ -0,0 +1,35 @@
+package index
+
+import (
+	_ "embed"
+)
+
+//go:embed builtins/README.md
+var builtinsReadme string
+
+// BuildBuiltins returns the synthetic "wire" module that documents canonical
+// Einherjar application wiring conventions. The content is authored as
+// markdown in builtins/README.md and embedded at compile time.
+//
+// The returned module participates in list_modules, get_module, and
+// get_example exactly like a real Einherjar module — applications can ask
+// the MCP server for "wire" knowledge the same way they ask for "core" or
+// "web" knowledge.
+func BuildBuiltins() Module {
+	m := Module{
+		Name:        "wire",
+		ImportPath:  "(application internal/wire)",
+		Purpose:     extractPurpose(builtinsReadme),
+		Readme:      builtinsReadme,
+		DependsOn:   []string{},
+		SubPackages: []SubPackage{},
+		Symbols:     []Symbol{},
+		ADRs:        []ADR{},
+		Compliance: Compliance{
+			InterfaceAsserts: []InterfaceAssert{},
+			Tests:            []ComplianceTest{},
+		},
+	}
+	m.Examples = extractExamples("wire", builtinsReadme)
+	return m
+}