Resolve wsproxy address by resource group ID

Goal

Session app-proxy routing currently looks up the scaling group's wsproxy address by the session's scaling group name (services/session/service.py ~:1328-1332 via get_scaling_group_wsproxy_addr). Switch the lookup to resource_group_id so app routing survives the name-column drop.

Scope

- repositories/session (repository.py ~:193, db_source/db_source.py ~:345): id-based variant of get_scaling_group_wsproxy_addr (WHERE ScalingGroupRow.id == :id).
- services/session/service.py call site uses SessionData.resource_group_id (depends on the read-model story).

Success Criteria

- [ ] Starting a session app routes through wsproxy with the id-based lookup (verify on live server via ./bai / web)
- [ ] Session without a resolvable resource group produces the same error semantics as before
- [ ] pants test passes for affected packages

JIRA Issue: BA-6711

Start in repositories/session/repository.py around line 193 and db_source/db_source.py around line 345, then inspect the service.py call site around lines 1328-1332 and SessionData.resource_group_id. Verify session app routing and the unresolved-resource-group error behavior, then run pants test for the affected packages. Done means id-based wsproxy resolution works through ./bai or the web interface.

Written by the indexing model from the issue text.