Add a linear backoff strategy alongside exponential

Exponential backoff is the right default for most jobs, but it's a poor fit for some: a job hitting a downstream system with a known, fixed recovery time (e.g. "this dependency's health check flaps for about 30 seconds after a deploy, then it's fine") is better served by evenly-spaced retries than by the rapidly-widening gaps exponential backoff produces. Without a configurable strategy, every job owner is forced into one retry shape regardless of what actually matches their target's behavior -- leading some to work around it by setting an artificially high max_retries just to get enough total retry attempts within their expected recovery window, which then also changes when the job gets dead-lettered.

A backoff_strategy column was added to jobs (TEXT NOT NULL DEFAULT 'exponential'), and pkg/executor.NextAttemptFor(strategy, attemptCount) exists as an entry point, but only handles "exponential" (by delegating to the existing NextAttempt) and "" (empty, same default). Anything else panics with "TODO(ticket-E7): backoff strategy ... not implemented".

1. Call pkg/executor.NextAttemptFor("linear", 3).
2. Observe: a panic, "TODO(ticket-E7): backoff strategy linear not implemented", instead of a computed time.

This is a small, self-contained addition to an existing dispatch function -- the hard part isn't the arithmetic, it's recognizing that this needs to compose with everything else already built around NextAttempt (jitter, the existing cap) without that becoming a required part of this ticket's scope.

Look at NextAttempt right below NextAttemptFor for the existing pattern (compute a delay, apply jitter, add it to time.Now()). A linear strategy needs the same shape with a different delay formula -- pick a reasonable fixed base delay (e.g. 10 seconds) multiplied by attemptCount.