monitor: publish signed+sealed state reports for monitoring

[ThomasWaldmann]

After create/prune, the borg client now publishes a small state report into the repository's new monitoring/ namespace. The report is signed (Ed25519) and sealed (HPKE, RFC 9180) using key material derived from the existing borg key, so the untrusted repository server can neither forge nor read it - it can only relay it.

The new borg monitor command reads, verifies and decrypts the reports from from the repository using the monitoring key, applies a freshness window (--max-age) and exits non-zero if the report is missing, stale, unsigned or unsuccessful.

borg monitor --key (which needs the unlocked borg key) derives and prints BORG_MONITORING_KEY for the monitoring host; that value only allows verifying and decrypting the state reports, not creating them. It also does not give access to other data or metadata in the repository.

Unencrypted (--encryption none) repos have no key to derive the monitoring key from, so their reports are published as unsigned, unencrypted plaintext and these reports are flagged untrusted on read.

borg monitor --json outputs report(s) in json format.

borg monitor --keep=N keeps the latest N status reports (default: 500), older reports are deleted. --keep=0 disables this.

borg monitor reads all reports and prints, per archive series (and per maintenance command), the latest status and freshness; --name / --command restrict the output. The exit code is the worst across all units.

Requires OpenSSL >= 3.2 (for the built-in HPKE API).

Also: reports record host/user and are grouped per backup job (host, user, command, archive series), so several hosts backing up the same series name to one repository do not mask each other; --host / --user restrict the output. delete, undelete and transfer publish reports as well.

Hardening (review follow-up)

The last three commits fix issues found while reviewing this PR - all of them ways the untrusted repository server could still influence what the monitor concludes:

• Replaying a report to mask a failure. Object names are plaintext and thus under the server's control, but the reader used their order to decide which report per job was the newest. The server could copy an old, validly signed "success" to a new, later-sorting name and shadow a newer failure for the whole --max-age window. The latest report per job is now chosen by the signed timestamp inside the report, and the object name is bound into the HPKE aad, so a sealed report only opens under the name it was published as.
• Downgrading a failure to a warning. The server could drop the sealed report it cannot forge and put an unsigned "success" of its own in its place; that came back as merely untrusted, i.e. a warning. Once a monitoring key is configured, an unsigned report can no longer be genuine and is refused like any other verification failure.
• Trusting the contents of an unsigned report. The body of an unsigned report is whatever the server serves. A body that is not a JSON object crashed borg monitor with a traceback, a list where a string belongs crashed it while grouping, and a report without a status counted as a success. Reports are now shape-checked before the reader uses them.

Known residual limitation: the server can still delete the newest report, which reverts the view to the previous one until it goes stale (--max-age). Detecting deletion requires state on the monitoring side and is out of scope here.

[codecov]

Codecov Report

❌ Patch coverage is 90.25974% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.34%. Comparing base (28de45c) to head (421d796).
⚠️ Report is 4 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/borg/monitoring.py	88.52%	11 Missing and 3 partials ⚠️
src/borg/archiver/monitor_cmd.py	90.35%	8 Missing and 3 partials ⚠️
src/borg/archiver/delete_cmd.py	66.66%	0 Missing and 2 partials ⚠️
src/borg/archiver/transfer_cmd.py	80.00%	2 Missing ⚠️
src/borg/archiver/undelete_cmd.py	83.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9788      +/-   ##
==========================================
- Coverage   85.83%   83.34%   -2.49%     
==========================================
  Files          95       98       +3     
  Lines       17034    17335     +301     
  Branches     2607     2652      +45     
==========================================
- Hits        14621    14448     -173     
- Misses       1673     2163     +490     
+ Partials      740      724      -16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.