feat(backups): workload service control, pgBackRest paths and backup state accessors

[marceloneppel]

Issue

Unit 04 of the charm-to-library migration ports the backup and restore subsystem into the library. That port cannot start yet: the workload layer has no way to address a service by name (the abstract start_service took no argument and neither substrate implemented it), Paths does not expose the pgBackRest log directory, and every backup/restore coordination field is read through the untyped databag escape hatch with the key spelled out at each call site.

Solution

Lay the scaffolding the backup port lands on. No backup logic moves in this PR.

• pgBackRest log directory and the two machine-charm snap service names become literals, one constant per substrate rather than one shared string: the snap keeps the log directory unversioned beside the other workload logs, while the Kubernetes charm scopes it under the version subtree of the mounted logs storage.
• The log directory resolves through Paths, keeping that divergence out of the backup manager, which would otherwise have to branch on the substrate to build a path.
• Typed stanza and restore-state accessors name each key once on the state object, so a rename or a scope mistake is one edit rather than a search. The stanza needs a cross-scope reader because it is published by whichever unit is primary and only later adopted by the leader, so consulting one databag alone is not enough. Field names are left exactly as the charms write them, so a cluster mid-restore survives the adoption.
• Workload services are addressed by name — start, stop, restart, reload and query — so the manager can express the pgBackRest lifecycle without knowing whether it is talking to snapd or Pebble. reload_service is the one primitive whose meaning differs: Pebble can signal a running service to re-read its configuration, the snap layer offers no signal channel, so on machines the only available reload is a restart, which is what the machine charm already does today. Querying a service has to answer for names the substrate may not know — a snap revision predating a service omits it from its services mapping, and Pebble cannot be asked before the container is up; both read as not running rather than raising.

Unit tests follow in a separate PR, matching the code-then-tests split used for the earlier migration units.

Checklist

• I have added or updated any relevant documentation.
• I have cleaned any remaining cloud resources from my accounts.