Define and validate the supported client experience across platforms

[vincent10400094]

Follow-up to PR #1. The current complete package targets Linux amd64; the remote guide uses an emulated Linux container on macOS. Fixing credential persistence in that existing walkthrough belongs in PR #1. This issue concerns broader platform support and prioritization.

Acceptance criteria:

• Publish a support matrix that separates native client support from dispatcher/executor and bundled demo support.
• Decide which macOS, Windows/WSL and Linux architectures to support, based on the intended users; explicitly mark unvalidated combinations.
• For every newly supported client platform, test installation, connection, registration, re-login, job submission, logs and credential persistence across restart.
• Container instructions persist config/credentials with appropriate permissions and state clearly which components run in the container.
• Provide actionable unsupported-platform messages and document the supported alternative.

Coordinate Linux arm64 artifact work with #146 rather than duplicating it. Platform expansion is not automatically a blocker for an explicitly Linux amd64 stable release.

[vincent10400094]

Progress: #185, merged into dev via #228 (e4a621f), states the supported client platforms (Linux amd64 native, macOS through a container), marks Windows, WSL and Linux arm64 as not validated, and keeps macOS credentials in a named volume with mode 0600. Still open: a matrix separating client, daemon and demo support, an end-to-end run of the macOS container (so far checked only against the code), and unsupported-platform messages that point to the alternative.

[vincent10400094]

Closing: the acceptance criteria are met on main (fde88bb).

Implemented in #289, #305, #185. Evidence: Support matrix in README-install.md (macOS, WSL and arm64 marked not validated), docs/operations/client-container.md, and the unsupported-host refusal in scripts/install.sh.