Decouple the session-spec preparer chain from ownership scope

The session-spec preparer chain finalizes a SessionSpec that requires an ownership SessionScope (domain_id / domain_name / project_id), but no preparer rule ever reads or writes scope — it is pass-through input the preparer never touches. This forces every caller to supply a complete scope even when it is irrelevant to what the preparer resolves. In particular the DB-mutation-free compute-schedule (dry-run) path only needs node-fitting, yet it fails finalize validation purely because domain/project are unset.

**Introduce a scope-free type as the preparer's working type so the chain expresses exactly what it resolves.**

- Add SessionResourceSpec / SessionResourceSpecDraft (SessionSpec / SessionSpecDraft minus scope). The preparer and all rules operate on the resource draft and finalize into SessionResourceSpec.
- SessionSpec is composed from a SessionResourceSpec plus a resolved SessionScope via SessionSpec.from_resource_spec(); the enqueue path attaches scope after finalize, so its behavior and scope validation are preserved.
- SessionSpecDraft.to_resource_draft() projects the enqueue input onto the scope-free draft the preparer consumes; the compute-schedule path uses SessionResourceSpec directly and passes the resource group id explicitly.
- Replace SessionMetadata.scaling_group (name) with resource_group_id (ResourceGroupID), and make NoAgentsInResourceGroupError carry a ResourceGroupID.

Out of scope: wiring the compute-schedule API handler and resolving how (or whether) the dry-run authorizes resource-group access; this issue only relocates scope relative to the preparer.

JIRA Issue: BA-6880

Start by tracing SessionSpec and SessionSpecDraft, the preparer chain and its rules, then compare the enqueue and compute-schedule paths. Verify the resource-only draft and finalized resource spec no longer require scope, while enqueue still attaches and validates scope. Check the SessionMetadata and NoAgentsInResourceGroupError changes for consistent ResourceGroupID usage.

Written by the indexing model from the issue text.