fix: wire upload timeout_secs to HTTP read_timeout (fixes 499 on 50GB+ uploads)

[Gumbees]

Root cause

ImmichClient::with_bandwidth_limit hardcoded .read_timeout(Duration::from_secs(120)) and never read the configured UploadConfig.timeout_secs. The read_timeout is an inactivity timeout -- it fires when no response bytes arrive for the configured duration. On a slow backend (Orange Pi / Rockchip SBC), Immich can spend several minutes checksumming a 50 GB file after receiving the last upload byte; no response bytes flow during that window. After 120 seconds of silence, reqwest fires the timeout and drops the connection -- the server sees a premature client close and returns HTTP 499. The timeout_secs config knob (intended to control this) was dead-wired: set in config, never passed to the client.

Fix

• src/api/mod.rs: added timeout_secs: u64 param to with_bandwidth_limit; .read_timeout now uses it instead of the hardcoded 120s. ImmichClient::new (connection-test path used by settings/first-run UI) defaults to 3600s. Updated the comment block to explain that this is an inactivity-only timeout, deliberately NOT an overall timeout (a healthy 50 GB transfer at 10 MB/s takes ~83 min; an overall timeout would kill it).
• src/main.rs: passes config.upload.timeout_secs to with_bandwidth_limit at app startup.
• src/app.rs: apply_new_config switched from ImmichClient::new to with_bandwidth_limit, so both bandwidth limit and inactivity timeout track the live config when server settings change.
• src/config.rs: UploadConfig::default().timeout_secs raised from 300 to 3600 (1 hour); doc comment updated to describe inactivity-only semantics and the slow-backend use case.

No overall .timeout() was added -- the existing design deliberately omits it and that is preserved.

Users can raise timeout_secs in settings if their server needs more than an hour to process a single file.

Born-green gate

cargo test --locked         → test result: ok. 110 passed; 0 failed
cargo check --release --locked → Finished `release` profile
cargo clippy --all-targets -- -D warnings → Finished `dev` profile (zero warnings)
cargo fmt --all -- --check  → (clean, no output)

All four CI gates pass locally.