fix(archiver): rearchiveRange ignores context — cannot be cancelled on shutdown or HTTP timeout

## Bug 1 — rearchiveRange uses context.Background(), ignoring cancellation

**Location:** `archiver/service/archiver.go`, `rearchiveRange`

`rearchiveRange` hardcodes `context.Background()` for both `retry.Do` and `persistBlobsForBlockToS3`:

\`\`\`go
rewritten, err := retry.Do(context.Background(), rearchiveMaximumRetries, retry.Exponential(), func() (bool, error) {
_, _, e := a.persistBlobsForBlockToS3(context.Background(), id, true)
...
})
\`\`\`

This means:
- **Shutdown is not respected.** When the archiver is stopped, any in-progress rearchive continues running indefinitely, holding references to the beacon client and storage.
- **HTTP timeout is not respected.** The `/rearchive` handler has a 60-second middleware timeout (`serverTimeout = 60 * time.Second`). When the timeout fires, the HTTP response is aborted, but the underlying rearchive goroutine keeps running — a silent resource leak for large slot ranges.

## Bug 2 — Structured log format string in waitObtainStorageLock

**Location:** `archiver/service/archiver.go`, line 244

\`\`\`go
a.log.Crit("failed to write to lockfile: %v", err)
\`\`\`

The `%v` verb is passed as a positional argument to the structured `go-ethereum` logger, which treats it as a key name, not a format directive. The error value is silently lost from the log output. Should be:

\`\`\`go
a.log.Crit("failed to write to lockfile", "err", err)
\`\`\`

Start in archiver/service/archiver.go at rearchiveRange and waitObtainStorageLock, then trace the /rearchive entry point and its context into the service. Verify that shutdown and the 60-second HTTP timeout stop rearchive work, and that lockfile failures retain the error in structured logs.

Written by the indexing model from the issue text.