librivox.fetch: pairing, sweep and lane edges #71

Follow-ups from v2.7.0 batch B (KodeStar/audiosilo-server#384, #70, KodeStar/audiosilo-frontend#297).

Batch B's librivox.fetch work (#69: outages keep staged sections, a 7-day staging sweep, meta 4xx refusals fail fast, the state records the server id, a parked fetch frees the download-lane slot) left these edges from the full review and the fix round.

• Server id stamped at plan time. The state's server id is taken when the fetch is planned, not checked against the server the run talks to when it starts, so a re-pair in between can slip through. A proper fix binds a run to one pairing.
• An empty server id counts as the same server.
• Sweep race. A job claimed between the sweep reading the job row and sweepOne can lose a state older than 7 days. The cost is a re-download, not data loss.
• A parked audible.import still holds the download-lane slot. Batch B frees the slot only for a parked LibriVox fetch.
• A state whose library never returns is kept forever. Give it an end (for example the same 7 days once the mapping is gone).
• Duplication with audiblejob. The staging, sweep and lane code repeats audible.import's; move the shared parts into one package.
• Staging folders with no state are never swept.
• Owed live check: a fetch parked on a lost mapping lets an Audible import or podcast job run, then resumes.
• Placement time in the fetch state (Bridge half of LibriVox add: identity edges after adopted audiosilo-server#385). After the fix round, adopted is false only when this run renamed staging into place, so a run that renames and then fails its rescan retries with adopted: true and the server keeps a deleted earlier book's leftovers at that path. Record the placement time in the state and send it as an additive result field next to adopted (internal/librivoxjob/librivoxjob.go:115); the server drops only rows older than it.