* Refresh Docker build tooling and container documentation
## Summary
Refresh the Docker container build tooling and align the Docker and Podman documentation with the container bases already used by `master`.
## Changes
- Update the Go builder used for gosu:
- `1.25` → `1.27`
- Update gosu across all container variants:
- `1.17` → `1.19`
- Parameterise the gosu version in the Debian Dockerfile.
- Update Docker and Podman documentation to reflect:
- Fedora 44
- Alpine Linux 3.24
- Debian 13 / Trixie
* Update Dockerfile-debian
This PR adds a new machine-readable runtime status capability for long-running `--monitor` operation.
When the client is running in monitor mode, it now maintains:
```text
<configuration directory>/monitor-status.json
```
alongside the existing configuration and application state files.
The status file provides a lightweight external view of the running monitor without requiring log parsing, additional Microsoft Graph requests, database inspection or execution of `--display-sync-status`.
### Runtime information exposed
The JSON status includes:
- application PID and per-process instance identifier
- configured operating mode
- configured monitor interval
- current monitor state
- application runtime
- monitor loop count
- current cycle start time
- last completed loop time
- whether the current process has completed its first successful synchronisation
- successful synchronisation cycle count
- last successful synchronisation time
- result and duration of the most recent cycle
- failed download count
- failed upload count
- failed Recycle Bin operation count
- Microsoft OneDrive service reachability
- current system-time validation state
All timestamps are emitted in UTC using an ISO-8601/RFC-3339-style representation so that monitoring systems can consume them consistently and convert them to local time when presenting them to users.
### Behaviour
Monitor runtime status is enabled by default:
```text
monitor_status = "true"
```
and may be disabled explicitly:
```text
monitor_status = "false"
```
The status file is:
- written with restrictive permissions
- updated using temporary-file + atomic rename semantics
- updated only at meaningful monitor lifecycle points rather than for individual file operations or notification events
- removed during a clean application shutdown
An abnormal termination such as `SIGKILL` or system power loss may leave the last status snapshot behind. A new monitor process immediately replaces any previous state with a new process instance and resets initial synchronisation readiness.
Status publication is deliberately non-fatal. Failure to write the runtime status file does not alter or interrupt normal synchronisation behaviour.
### Purpose
This provides a stable visibility layer for external tooling such as:
- Docker / Podman health and readiness checks
- systemd monitoring
- shell automation
- monitoring and observability platforms
- future graphical or management interfaces
In particular, consumers can determine whether a newly started monitor process has completed at least one successful synchronisation cycle without parsing normal application log output.
### Relationship to `--display-sync-status`
This capability does **not** replace or change the semantics of `--display-sync-status`.
The two interfaces answer different questions:
```text
monitor-status.json
-> What is the running monitor doing, and did its synchronisation
processing complete successfully?
--display-sync-status
-> Are the local filesystem and Microsoft OneDrive currently
converged?
```
This distinction is important for one-way operating modes.
For example, a `--download-only` monitor may successfully complete all permitted download processing while local-only files remain present.
In that situation:
```text
monitor-status.json
-> last cycle successful
--display-sync-status
-> NOT IN SYNC
```
Both results are correct: the configured monitor operation completed successfully, while the local and remote data states are not identical.
### I/O impact
The runtime status file is intentionally small and is not used as a high-frequency heartbeat.
It is updated during monitor lifecycle/state transitions such as:
- monitor startup
- synchronisation cycle start
- synchronisation cycle completion
- relevant condition changes
- orderly shutdown cleanup
It is not rewritten for individual uploads, downloads, inotify events or WebSocket notifications.
This keeps the additional filesystem I/O negligible relative to the database, filesystem and network activity already performed by normal monitor operation.
### Documentation
Documentation has been updated to cover:
- the new `monitor_status` configuration option
- runtime status file location and lifecycle
- JSON fields and timestamp conventions
- Docker and Podman observability use
- relationship to `--display-sync-status`
- application architecture integration
* Correct Docker documentation as to distribution versions being used for the Docker images. This should have been updated with the December 2025 update
* Update docker documentation to clarify docker mounts as read-write and how to make them read-only for certain scenarios
* Update Ubuntu install guide to fix that ARMHF packages are available for those platforms on the OpenSuSE Build Service
* Add Docker environment variable 'ONEDRIVE_THREADS' to control the value for the number of worker threads used for parallel upload and download operations.
* Revert back to v2.5.5 performSessionFileUpload() and apply minimal change for upload session offset handling to prevent desynchronisation on large files
* Add specific 403 handler for when the upload session URL itself expires
* Add 'file_fragment_size'
* Clean up debug logging output
* Add 'tempauth' to spelling words
* Update documentation URL's
* Ensure that on each fragment upload, whilst the application is using the 'tempauth' for session upload, the global OAuth2 token needs to be checked for validity and refreshed if required
* Add limit check for 'file_fragment_size' option
* Add to default 'config' file
* Update documentation for 'file_fragment_size'
* Add 'file_fragment_size' to --display-config output
* Add --file-fragment-size option to enable use via Docker option
* Add to manpage
* Update Docker entrypoint
* Update Docker | Podman documentation
* Update logging output to include connection method to URL
* Update Upload Session URL expiry update to include UTC and LocalTime values
* Update comment which was dropped / missed
* Clarify that this is the OAuth2 Access Token
* Clarify that the expiry timestamp is localTime
* Update PR with dynamic use of fragment size if fileSize > 100MiB
* Enforce multiple 320KiB for fragment size to align to Microsoft documentation
* Fix Docker entrypoint and confirm working for ONEDRIVE_FILE_FRAGMENT_SIZE
* Change 'defaultMaxFileFragmentSize' to 60
* Revise fragmentSize calculation to be as close to 60 MiB as possible without breaching Microsoft documented threshold
* Due to the significant issues with Debian and it's default version of 'curl' ensure that the Debian Docker image will update 'curl' from the relevant backports repository to avoid these issues
