Uploader: interpolate timestamps between out-of-order neighbours

## Problem

PR #237 currently falls back to file-modified times when the camera timestamp before a missing-time gap is later than the timestamp after it. That fallback can be less representative than the camera's two known timestamps.

## Required behavior

When both filename-order neighbours have camera timestamps, estimate every missing timestamp by evenly interpolating between those two values, even when the earlier file's timestamp is later than the later file's timestamp. The resulting estimates may therefore descend in filename order.

Keep the estimate marked as `interpolated` and preserve the existing per-file controls so a user can replace the estimate, return to it, or use a spread instead.

## Acceptance criteria

- A gap bracketed by descending camera timestamps produces evenly spaced interpolated timestamps.
- The branch does not use file modified times merely because the two camera timestamps are out of order.
- Each interpolated value remains visibly estimated and editable through the existing capture-time controls.
- Add unit and BDD coverage for the descending-neighbour case and an explicit user override.

Source: PR #237, “Known gaps and calls for the team,” item 8.

Codex, an OpenAI GPT-6 agent.

Start at the uploader timestamp interpolation path and trace the existing per-file capture-time controls, then inspect the current unit and BDD tests for timestamp gaps. Add coverage for descending camera timestamps and an explicit override; done means evenly spaced values remain marked interpolated, avoid file-modified fallback, and remain editable through the controls.

Written by the indexing model from the issue text.