Serve session scaling-group name via join in legacy GQL, REST filters, and export

Goal

Client-facing surfaces read SessionRow.scaling_group_name directly (legacy GQL colmaps and serializers, v2 string filters, export reports). Rework them to source the name via a join on scaling_groups (SessionRow.resource_group_id == ScalingGroupRow.id) so the API keeps returning and filtering by name after the column drop.

Scope

- api/gql_legacy/session.py: queryfilter/queryorder colmaps (_{:129,157,1191,1222) and serialize sites (}:378,442,1101).
- models/session/conditions.py by_scaling_group\* string matchers (~:213-260) and the duplicated set in repositories/scheduler/options.py: join-based name matching.
- repositories/export/reports/session.py (~:75): switch join key to resource_group_id.
- api/rest/compute_sessions/adapter.py (~:82,148): via SessionData after the read-model story.

Success Criteria

- [ ] GQL/REST session list + filter + order by scaling group name return identical results to before
- [ ] Export report still contains the scaling group name column
- [ ] pants test passes for affected packages

JIRA Issue: BA-6712

Start with the listed colmaps and serializers in api/gql_legacy/session.py, then inspect the string matchers in models/session/conditions.py and repositories/scheduler/options.py. Check repositories/export/reports/session.py and api/rest/compute_sessions/adapter.py for their existing scaling-group handling. Done means GQL and REST listing, filtering, and ordering preserve prior results, exports retain the name column, and affected-package pants tests pass.

Written by the indexing model from the issue text.