fix: accept both hyphen and underscore in v2 profile type names

[himorishige]

What

Makes the v2 profile config (switchyard serve --config profiles.yaml) treat - and _ as equivalent in the type: discriminator, so a profile type spelled with either separator resolves to the same profile.

Why

The quickstart teaches the legacy route bundle with snake_case type names (type: random_routing), while v2 profile configs use hyphenated names (random-routing, llm-routing, latency-service). Copying type: random_routing into a profiles.yaml fails with unknown profile type. Since #20 the v2 names are themselves mixed (random-routing vs stage_router), so either separator is a reasonable spelling for any type.

This is the code-unification follow-up to #19 (a docs note), per the request there to fix it in code rather than documentation. #19 is closed in favor of this.

How

parse_profile_config (the generated dispatch in profiles/macros.rs) now compares the requested type against each registered profile type treating - and _ as equal, via a small non-allocating byte scan. Single dispatch point; no per-profile or macro-attribute changes. Unknown types still error with the user's original spelling.

• random_routing → random-routing
• stage-router → stage_router
• hyphenated/underscored spellings of llm-routing, latency-service, etc. all resolve

Tests

• New tests/config.rs::profile_type_separators_are_normalized_during_resolution: llm_routing, stage-router, and latency_service resolve to their canonical types and build.
• Existing unknown-type / missing-type / empty-type tests unchanged.
• cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, and cargo test --workspace all pass (toolchain 1.94.0).

Notes

• Backward compatible: existing hyphenated (and stage_router) configs are unaffected.
• Scope is the v2 --config path (the failing side); the deprecated --routing-profiles bundle is unchanged.
• Registered profile type names must stay unique under separator folding (they are today), so dispatch is unambiguous.
• Normalization is applied at the config dispatch point (parse_profile_config). The resolved plan and runtime always report the canonical type name; ProfileConfigDocument::profile_type() still echoes the spelling written in the file. If you'd rather have the document accessor also report the canonical name, I can canonicalize at ingestion instead — let me know your preference.
• Docs are intentionally not touched (the confusion this documented is now removed in code).

[ayushag-nv]

Looks good to me. Thanks for the contribution.