Add API key authentication for the jobs API

Every write endpoint under /v1/jobs -- create, delete, enable/disable, reschedule, trigger -- is currently reachable by anyone who can reach the port, with zero authentication. For a local demo that's fine; for anything deployed beyond a fully trusted private network, it means anyone who can route to the service can create arbitrary jobs that POST to arbitrary URLs with arbitrary payloads (a server-side request forgery primitive), delete or disable existing jobs, or trigger jobs on demand. This is the kind of gap that's easy to overlook precisely because the demo/local experience works perfectly without it -- the risk only appears once someone actually deploys this somewhere reachable by more than themselves.

internal/api/server.go has the scaffolding for this already: a Server.apiKey field, a Server.SetAPIKey setter, and a requireAPIKey middleware already wired into the /v1/jobs route group -- but the middleware itself is a no-op that calls next.ServeHTTP unconditionally. Every request passes through regardless of s.apiKey or any Authorization header.

1. Call s.SetAPIKey("secret") on a Server.
2. Send GET /v1/jobs with no Authorization header.
3. Observe: HTTP 200, instead of the expected 401.

This needs to be an opt-in gate, not a hard requirement, because nothing in cmd/chronos/main.go currently calls SetAPIKey -- making the check unconditionally required would break the existing demo flow and every other ticket's test that hits the HTTP API without a key. The middleware needs to check s.apiKey != "" before enforcing anything.

Look at how s.instanceID or other Server fields are read inside a handler for the pattern; requireAPIKey needs to inspect r.Header.Get("Authorization"), compare it against an expected "Bearer " + s.apiKey value, and call next.ServeHTTP only on a match (or unconditionally when s.apiKey == "").