backups: the collection interval was never actually readable

Backup-NtlarsSettings reads backups_intervalhours from /api/settings/public,
because it runs before it holds any credential, and its Get-IntervalHours falls
back to 24 on any failure. The plugin never declared the key public, so the
endpoint did not return it, the fallback fired on every PC, and the setting
looked configurable in the UI while changing nothing. The fleet log shows the
symptom plainly: "Throttled: last attempt under 24h ago", every cycle,
regardless of what the setting said.

Declared public. A collection cadence is not a secret. backups_shareroot stays
private - it is internal topology - and the test asserts both directions so a
later edit cannot quietly widen it.

Same defect as the 3D parts kiosk label prefix already in this changelog: a
logged-out reader against an allowlist its key was not on. Worth noticing that
the pattern has now bitten twice.

CHANGELOG.md

@@ -32,6 +32,11 @@ ADR-007 and ADR-002.
   PC's revisions can no longer push out a quiet PC's only backup, and the
   revision diff compares against the same PC's previous revision rather than
   another PC's.
+- The backup collection interval could not actually be changed. The collecting
+  script reads `backups_intervalhours` from the public settings endpoint before
+  it holds any credential, but the plugin did not declare the key as public, so
+  the endpoint never returned it and the script fell back to its built-in 24
+  hours - silently. The setting looked configurable in the UI and was not.
 - A backup export containing a value with an empty right-hand side (`Name=`)
   failed to parse, and with it the whole file, so that machine could never be
   backed up. The form is not strictly legal but occurs in real exports. It is