Templatize the docker-prune systemd unit for multi-host use

[JSONbored]

Problem: The example systemd unit for periodic Docker pruning hardcodes a single working directory — one unit serves exactly one host today.

Area: ORB / Fleet ops

Proposal: Convert it to a templated unit (@.service) parameterized by instance, so it can be reused across a fleet without hand-editing per host.

Deliverables:

• A templated systemd unit usable across multiple hosts.

AMS Cloud Readiness cross-reference (added 2026-07-12)

See also #5220, #5222 in the new AMS Cloud Readiness milestone (#28) — the AMS-side parallel to this exact problem, already citing this issue as precedent. Keep both sides in sync if either design changes.

[linear-code]

JSO-3554

[JSONbored]

Releasing from maintainer-only — this milestone is genuinely gated on the undecided 'should we build hosted, and when' question, but this specific issue isn't. Pure refactor with zero tenant/business coupling: converting a hardcoded systemd unit into a standard parameterized instantiated unit (foo@.service), a well-known generic ops pattern useful for any fleet of hosts — no pricing/SLA/hosted-or-not decision, no trust/safety-critical shared state.