fix(downloads): give the three download-finalization settings a reader again

[m4bard]

Fixes #894.

Settings > Download has six numeric inputs. The last three, Download Completion Stability, Missing-source Retry Initial Delay and Missing-source Max Retries, validate, persist, round-trip through the API and have frontend defaults, and nothing in the backend read any of them.

They are not controls that were never wired. All three had consumers, added alongside the properties in e7989da3, and the reads were lost in 1d6a8e97 when #535/#492 restructured download importation and deleted the two files holding them.

Stability window

Finalization began in the same pass that first saw the client report completion, so the setting's own default of 10 seconds was ignored along with any value an operator chose.

The monitor now holds the transition into Completed until the client has kept reporting it for the configured window.

It holds the transition rather than the update, so progress and size still persist and the row stays current while finalization waits. And it reverts the status rather than skipping the write, which means the next cycle sees the same transition again and can let it through once the window has passed, without anything else needing to remember that one is pending. A window of zero finalizes in the same pass, exactly as before.

Retry budget

MaxRetries is a per-job column that EnqueueAsync never set, so every job got the property default of 3 whatever the setting said.

It is applied by the processor on each attempt rather than baked in at enqueue, for two reasons. The budget then follows the current setting for jobs already in flight. And DownloadProcessingJobService stays clear of IConfigurationService, which DownloadProcessingJobService_ResolvesWithoutAdaptersOrHostedWorkers pins on purpose. My first attempt injected it there and broke that test, which was the test doing its job.

Retry delay

ScheduleRetry now takes the configured initial delay.

The old expression also had an off-by-one. It read RetryCount after incrementing it, so the first retry waited a minute while the summary comment above it said 30 seconds and the inline comment beside it said 0.5 minutes. Neither matched the code. The first retry now waits exactly the configured delay and each later one doubles it.

One thing I would rather you decided

The settings are named for the missing-source case, and the old code read them only in that branch. In the current architecture there is a single per-job retry mechanism shared by every failure path in the processor, so applying them to some branches and not others would give an operator a control whose effect depended on which internal branch failed.

I have applied them to the job. If you would rather they stayed scoped to the missing-source branches, that is a smaller change and I will make it.

Tests

Four existing tests drove a download to completion and asserted on the result in the same cycle. They passed because the stability setting had no reader. They now say which window they depend on rather than inheriting it.

Seven added: three on the backoff arithmetic, three on the stability window, one theory on the retry budget. The suite has no fake clock, so the stability tests use a small adjustable TimeProvider rather than sleeping.

Checked by reverting each of the three reads in turn and confirming the matching test fails: the held transition, the backoff expression, and the configured retry budget.

---

Worked through with Claude Code at my direction. The claims above were checked by running them rather than by reading, and I reviewed this before posting.