Send workshop machine ID with workshopctl requests

[tlm]

Description

Forward the LXD-provided workshop machine ID from workshopctl to workshopd in the workshop-machine-id HTTP header.

This enables follow-up secrets work: workshopctl and workshopd need a shared workshop identity to communicate and validate the workshop from which a secret request originates. The daemon records the received ID in debug request logs to support diagnosis.

This PR intentionally only transports the identifier. It does not validate the ID or authorise secret access; those checks will be added in follow-up secrets PRs.

Self-review quick check

• Make decisions that cost a lot to reverse explicit in the PR description.
• Avoid nested conditions.
• Delete dead code and redundant comments.
• Normalise symmetries by sticking to doing identical things identically.
• Check that coupled code elements, files, and directories are adjacent.
• Put variable declaration and initialisation together.
• Divide large expressions into digestible and self-explanatory ones.
• Put a blank line between two logically different chunks of code.
• Follow the style guide for new error messages.

Docs

• I confirm the PR has no implications for documentation.

[jonathan-conder]

just FYI from machine-id(5):

This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.

I don't think the socket necessarily counts as the "network," but it seems like a good idea regardless.

[tlm]

@jonathan-conder good spot.

I looked into the available options. For Workshop LXD containers,
/etc/machine-id is derived from the instance’s volatile.uuid. The
host-side LXD API already exposes that authoritative value to workshopd,
which Workshop uses when configuring the instance template used during
creation and restore.

In this request path, workshopctl is not disclosing the value to a new
network or untrusted service: the container already has the machine ID, and
workshopd already has access to the corresponding LXD instance UUID. The
request travels over the existing private Unix-socket proxy. I have also
removed it from daemon debug logging so it is not retained there.

workshopd already has the authoritative raw value through LXD, so deriving
an HMAC would not hide information from the request recipient. It would only
replace one representation of an identifier that workshopd can already
derive with another representation.

A client-side fixed HMAC key also does not add an authentication boundary:
processes in the workshop can read the machine ID and inspect the
workshopctl binary containing the key. workshopd could recompute the
expected HMAC and compare it, but could not use it to recover a machine ID it
did not already obtain from LXD.

I am inclined to retain the raw value for this private host/container
validation path. If a future secrets flow sends this identity beyond that
boundary, we should introduce an application-specific derived identifier at
that point. I am open to stricter alternatives or a different threat model.