Add deterministic capability exposure ordering in initialization responses

Problem
Capability ordering in initialization responses can vary, producing snapshot churn and non-reproducible handshakes for clients/tests.

Why now
Reference servers should provide stable protocol surfaces and deterministic initialization behavior.

Expected behavior
Equivalent configurations produce byte-stable capability ordering in initialization responses.

Acceptance criteria

• Capability exposure ordering is deterministic across runs.
• Existing capability semantics unchanged.
• Tests assert stable init response ordering for equivalent config.

Evidence packet

• Commit under test: 04cce79b4c2bbaa313095e9c2a466381f5fd1e64
• Runtime environment: macOS Darwin 25.3.0 arm64, Node 22.19.0
• Minimal repro:
  1. Start server repeatedly with same config.
  2. Capture init response capability sections.
• Expected: stable deterministic ordering.
• Actual: ordering may vary and cause churn.

Start by locating the initialization response construction and the code that assembles its capability sections. Reproduce the issue by starting the server repeatedly with the same configuration and comparing captured responses. Done means equivalent configurations produce stable capability ordering while existing capability semantics remain unchanged, with a test asserting the ordering.