STOMP over WebSockets connections are never blocked by a resource alarm

[!NOTE] This issue was drafted by Claude (Anthropic's Claude Code) under the direction of @lukebakken. The code references were verified by reading the current main. This was found while auditing alarm registration for #17238 and is not caused by it.

rabbit_web_stomp_handler carries the full resource-alarm apparatus but never registers for alarms, so a STOMP-over-WebSockets connection is never told to conserve resources and keeps publishing at full rate during a memory or disk alarm on any node.

Present in the module:

• a conserve_resources field in #state{}, initialised to false
• a websocket_info({conserve_resources, Conserve}, State) clause that sets it
• control_throttle/1, which reads it to decide whether to throttle

Missing: any call to rabbit_alarm:register/2. Nothing in the tree sends {conserve_resources, _} to this process, so that clause is dead code and the field never leaves false.

Every other protocol registers: rabbit_reader, rabbit_amqp_session, rabbit_mqtt_reader, rabbit_web_mqtt_handler, rabbit_stomp_reader, rabbit_local_shovel and rabbit_stream_reader. rabbit_web_mqtt_handler is the closest analogue and shows the shape this one should take, including seeding the initial state from what register/2 returns.

Worth noting that #10293, a closed pull request for asynchronous alarm registration, covered AMQP 0-9-1, AMQP 1.0, MQTT and STOMP but not web-stomp either.