[vvoytovych]

The shell session alerts name a service and a team that the platform's service catalog does not list, so no route reaches a team and each of them lands in the catch-all channel, as several did in both environments over the last two weeks.

They now name compute and its team, build, as the catalog's row for compute names them, so their route reaches the build team's channel.

A new test reads the shipped rules, so it checks what deploys rather than a copy.

Changes

Change	Effect
The six shell session alerts	name compute as their service and build as their team
A new rule test	checks that every shell session alert names compute and build, and that the availability page fires with them

Test plan

• The new test fails on the previous service and team and passes on these
• Routed through both environments' live alert trees, every shell session alert reaches the build team's channel, and the pages stay pages
• After the release reaches production, the next shell session alert posts to the build team's channel
• For a week after the release, no shell session alert reaches the catch-all channel in either environment

[ecv]

Approve.

The six shell session alerts now reach the build team's channel instead of the catch-all, including the two pages.

• Production's service catalog names datum_service: compute with team: build, and has no compute-shell-sessions row, which is why the old labels routed nowhere.
• Only labels change, so no alert's expression changes.

Follow-ups:

• No workflow, Taskfile or Makefile runs test/alerts/test-shell-sessions.sh, so the new test does not gate a PR. The same holds for test-reconcile-storm.sh. Wire both into CI, or the next label drift lands unchecked.