feat: add --api-key flag for persistent external API access

[bketelsen]

Summary

Adds a static, non-expiring API key that enables external tools to access the Mesa API without relying on ephemeral per-run agent keys.

Problem

Mesa's current API keys are dynamically generated per-run, scoped to individual agents, and expire after 60 minutes. This makes it impossible for external orchestration tools, CI/CD pipelines, or wrapper agents to interact with Mesa's API — they can't obtain a valid key without being part of the internal agent roster.

Solution

A new --api-key <key> CLI flag (and MESA_API_KEY_EXTERNAL env var) that configures a persistent external API key:

# Start mesa with an external key
mesa --api-key my-secret-key -t enterprise 3001

# Use it from any external tool
curl -H 'Authorization: Bearer my-secret-key' http://localhost:3001/api/v1/issues

Changes

File	Change
cmd/mesa/main.go	Parse --api-key flag and MESA_API_KEY_EXTERNAL env, wire to API, print usage on startup
internal/handlers/api.go	Add SetExternalKey(), check external key in Auth() middleware before DB lookup, add GET /api/v1/issues list endpoint
internal/handlers/handlers_test.go	3 new tests: valid external key, wrong value, not set

Design Decisions

• No DB schema changes — the external key is stored in-memory as a SHA-256 hash, checked before the existing DB key lookup
• Synthetic agent context — external key resolves to a virtual external agent so endpoints that call agentFromContext() work correctly
• New list endpoint — added GET /api/v1/issues?status=&limit= since external callers need to list all issues (not just an agent's inbox)
• Backward compatible — no behavior changes when --api-key is not provided

Testing

All existing tests pass. 3 new tests added:

• TestAuthExternalKey — valid key returns 200 with external agent in context
• TestAuthExternalKeyWrongValue — wrong key returns 401
• TestAuthExternalKeyNotSet — without external key configured, falls through to DB lookup

Use Case

I'm building an orchestration layer where an external agent (running outside Mesa) creates work blocks, injects issues, and reads results via the API. The current ephemeral keys make this impossible without direct SQLite access.

[msoedov]

LGTM, thank you!