Artifact relay subscribe/unsubscribe now distinguish 'relay unavailable' from other refusals

What

• Subscribing to artifact updates now returns early with {outcome: 'skipped', reason: 'relay_not_served'} when the session's relay isn't served at all.
• Two new refusal reasons cover why a wake subscription couldn't register: relay_not_served (the cloud session can't register wake subscriptions at all) and relay_unavailable (the session's gateway refused to carry the subscription, commonly because the organization doesn't have it enabled).
• Unsubscribing from a live artifact frame now also reports a relay-unavailable/relay-not-served refusal distinctly (capturing the HTTP status or a "relay down" flag), tracked via a new unwatch_relay_unavailable telemetry event instead of being lumped into the generic unwatch_client_policy event.

Why Previously these relay-down situations were reported the same as an ordinary access refusal (subscribe_forbidden/unwatch_client_policy), making it hard to tell "you're not allowed" apart from "the relay infrastructure isn't available." Separating the reasons should make it clearer when a problem is on the user/org side versus an infrastructure limitation.