Clarify or implement runtime semantics for router.enabled

[MicroMilo]

Problem

router.enabled is exposed through the config/UI, but setting it to false does not currently change runtime behavior.

This appears to be an accidental config/runtime contract mismatch rather than intentional behavior: the config surface suggests that router behavior can be disabled, but the gateway runtime still creates and uses the router.

Current Behavior

• Users can set router.enabled: false in the config.
• The gateway runtime still creates the router runtime.
• Router-related defaults may still be normalized/populated.
• Routing features such as scenarios, fallback, token saver, and stats are not clearly disabled by this flag.

Expected Behavior

router.enabled should have a clear and enforced meaning.

Either:

1. The router is required and cannot be disabled, in which case the UI/config surface should stop presenting router.enabled as an effective toggle.

Or:

2. The router can be disabled, in which case the runtime should explicitly read router.enabled === false and disable the relevant router behavior.

Impact

This can mislead users into believing routing has been disabled when it has not. It also makes debugging routing behavior difficult because the saved config and runtime behavior disagree.

Evidence / Code Areas

Relevant areas to inspect:

• Config/UI surface that exposes router.enabled
• Runtime gateway creation path
• Router config normalization/defaulting path
• Router status/reload reporting

Product Decision Needed

Please decide which semantic is intended:

• Remove or rename router.enabled if the router is mandatory.
• Implement runtime support for router.enabled: false if the router should be optional.

Acceptance Criteria

• router.enabled: false is no longer a no-op.
• Either the UI/config no longer implies the router can be disabled, or the runtime actually disables router behavior.
• Runtime status/API responses accurately reflect the router enabled/disabled state.
• Tests cover the chosen behavior.