workspace-software: replace legacy hermes.service (no ExecCondition) on ensure when it is a known NaN render #152

Follow-up from the review of helmcode/nan-cloud-api#309.

Problem. Workspaces built from base images older than the versioned-1 layout have a hermes.service without ExecCondition=+/bin/grep -qx NAN_HERMES=1 /etc/hermes/env. Today the executor's ensure only enables or disables the unit. It never replaces the unit file, so these guests keep the old unit until Hermes is installed or updated.

Proposal (not implemented yet). In the executor's ensure hermes, replace /etc/systemd/system/hermes.service with the shipped one, then daemon-reload, when its sha256 is in KNOWN_SYSTEM_SHA256.

• No backup: it is a known NaN render, not a member edit.
• A unit whose sha is not known is left untouched, with a warning code.

Tests

• Executor fixture: a legacy unit with a known sha is replaced and gains the ExecCondition; an unknown sha is untouched and reports the warning; no *.nan-backup-* file is created.
• Contract fixture updated in internal/workspace/software/executor/testdata/contract/.

Tenant: NaN community (cloud-api executor, devops mkbase shas).