fix(doctor): time out the S3 probe and stream check results

[tink-bot]

vikunja doctor hung forever with zero output when files.type: s3 pointed at an unreachable but well-formed endpoint. Against http://10.255.255.1:9999 it produced nothing at all and had to be killed after 60 seconds.

Two compounding causes, both fixed:

• No deadline on the S3 calls. The backend passed context.Background() to every AWS call, so the probe blocked until the OS TCP timeout with no way to interrupt it. Write, Stat and Remove now take the caller's context, and doctor bounds the S3 checks with 12s. That is well above a healthy round trip including TLS and SDK retries, well under the OS TCP timeout, and the same order as the existing 5s Redis deadline.
• Nothing printed until every check finished. doctor.Run() collected all groups before PrintResults ran, so one stalled check withheld the whole report including the groups that had already passed. Groups now print as they complete. Order, formatting, the summary line and exit codes are unchanged.

Worth noting the hang was not in checkS3Storage — it was in the storage init that runs before it, which is why no output appeared at all rather than a partial report.

Measured: 60s+ (killed, no output) → 12.2s with the earlier groups printed immediately.

Local storage is untouched: it keeps context.Background(), and its full doctor output diffs clean against a binary built from the merge base. Missing credentials and malformed endpoints still fail instantly rather than waiting out the deadline.

Stacked on #3646. Based on doctor-pwd-assumption because both branches restructure pkg/files/filehandling.go and pkg/doctor/files.go. Rebase onto main once #3646 merges; review the three commits here rather than the combined diff.

How to verify

1. Write a config with files: {type: s3, s3: {endpoint: "http://10.255.255.1:9999", bucket: b, region: us-east-1, accesskey: k, secretkey: s}}.
2. Run time vikunja doctor against it.
3. Expected: it completes in roughly 12 seconds; the System, Configuration and Database groups print first, then ✗ Writable: S3 endpoint http://10.255.255.1:9999 did not respond within 12s.
4. Before this PR: no output at all, and the command had to be killed.

Then confirm the fast failures did not become slow:

1. Run doctor with an S3 config that omits accesskey. Expected: it fails immediately with S3 access key is not configured. Please set files.s3.accesskey, not after 12 seconds.
2. Run doctor with a malformed endpoint such as ht!tp://%%%bad. Expected: it fails immediately with was not a valid URI.

Then confirm local storage is unaffected:

1. Run doctor against a healthy local install. Expected: the full result set, in the same group order as before, completing in well under a second, exiting 0.

[github-actions]

Preview Deployment

Preview deployments for this PR are available at:

URL	Tag	Commit
https://pr-3654.preview.vikunja.dev	ghcr.io/go-vikunja/vikunja:pr-3654	latest
https://sha-78d5e3b0812e4d61bf1b8c690c9845fa4b10bcad.preview.vikunja.dev	ghcr.io/go-vikunja/vikunja:sha-78d5e3b0812e4d61bf1b8c690c9845fa4b10bcad	78d5e3b
https://sha-49006dc61a2a2cddca66959ae7decac721e2b9a8.preview.vikunja.dev	ghcr.io/go-vikunja/vikunja:sha-49006dc61a2a2cddca66959ae7decac721e2b9a8	49006dc
https://sha-9cd46c72024c24014fbd2255ec77fb2cb710b23e.preview.vikunja.dev	ghcr.io/go-vikunja/vikunja:sha-9cd46c72024c24014fbd2255ec77fb2cb710b23e	9cd46c7
https://sha-500d42bd3c5af0623da537cec88fa8aedf4e678f.preview.vikunja.dev	ghcr.io/go-vikunja/vikunja:sha-500d42bd3c5af0623da537cec88fa8aedf4e678f	500d42b

The preview environment will start automatically on first visit. Subsequent pushes to this PR will update the pr-3654 image — the preview picks up the new version on restart. The per-commit URLs point to a specific version and will not change.

Run locally with Docker

docker pull ghcr.io/go-vikunja/vikunja:pr-3654
docker run -p 3456:3456 ghcr.io/go-vikunja/vikunja:pr-3654

Last updated for commit 78d5e3b