feat: send x-machine-id header on OpenFrame TLS requests

[mikhailm-coder]

Summary

In openframe mode, osqueryd's own TLS requests (enroll, config, distributed read/write, logger, carve) were blocked with a 403 by the gateway's new machine-id firewall because — unlike orbit — osqueryd never sent the x-machine-id header.

• New OpenframeMachineIdProvider (openframe/): lazily reads the machine id written by openframe-client to the shared OpenFrame data dir (/Library/Application Support/OpenFrame/machine_id on macOS, /var/lib/openframe/machine_id on Linux, %ProgramData%\OpenFrame\machine_id on Windows) and caches it for the process lifetime; retries on every request until the file appears.
• TLSTransport::decorateRequest adds the x-machine-id header next to the existing openframe Bearer token when --openframe-mode is on — one choke point covering all osquery TLS endpoints.
• No new flags; the machine id file location is the same fixed contract orbit already uses (openframe_machine_id_provider.go in the fleetmdm fork).

Testing

Built for macOS arm64 and swapped into a live mmm-dev enrollment on a machine behind the active firewall:

• Provider log confirms the id loads: OpenFrame machine id loaded from: /Library/Application Support/OpenFrame/machine_id
• osquery enroll responses changed from the firewall's HTML 403 (Cannot parse JSON: Invalid value. Offset: 0) back to Fleet's JSON-level response — i.e. requests now pass the firewall and reach Fleet, identical to pre-firewall behavior.

🤖 Generated with Claude Code