Add ?enabled= filter to GET /v1/jobs

Operators managing more than a handful of jobs need to quickly answer "what's currently disabled?" or "what's actually running?" without eyeballing a full unfiltered dump. Today GET /v1/jobs always returns everything, so anyone building tooling on top of the API (a dashboard, an alert that pages when too many jobs are disabled, a cleanup script) has to fetch and filter client-side -- fine at 10 jobs, painful and wasteful at 10,000.

internal/api/jobs_handler.go's listJobs already parses ?enabled=true|false and calls s.jobs.ListFiltered(ctx, &enabled) when present. internal/store/jobs.go's ListFiltered is a placeholder that panics with "TODO(ticket-E1): ListFiltered not implemented". Because internal/api/server.go wraps every request in middleware.Recoverer, hitting this endpoint with ?enabled= today returns an opaque HTTP 500 instead of crashing the process -- but it's still broken.

1. Run the server and call GET /v1/jobs?enabled=true.
2. Observe: HTTP 500 instead of a filtered 200 response.

This is the simplest possible read-filter: one boolean column, one query parameter, no joins, no pagination interaction to worry about. It's a good first enhancement because the wiring on the HTTP side is already done -- the whole task is one SQL query.

Look at List and ListEnabled right above ListFiltered in internal/store/jobs.go for the exact query shape and column list (jobColumns) to match. ListFiltered needs to do the same thing but filter on jobs.enabled using the pointer's dereferenced value.