Add public API parity for bridge HAP enablement alongside Matter

Current Situation

Homebridge 2.x exposes bridge-level enablement for both HAP and Matter, but the public API is asymmetric.

The shipped source shows:

• Server.isHapEnabled(bridgeConfig) exists in dist/server.d.ts
• api.isMatterEnabled() exists in dist/api.d.ts

The source comments also state:

• HAP is “on by default; users opt out via bridge.hap.enabled: false”
• Matter is “opt-in; a bridge.matter block must be present and not explicitly disabled via bridge.matter.enabled: false”

This means HAP is configured at the bridge level, but the public plugin API only exposes the Matter side as a first-class runtime check.

Proposed Change

Add a corresponding public API accessor for HAP enablement, analogous to api.isMatterEnabled().

For example:

• api.isHapEnabled(): boolean

This would allow plugins/platforms to ask the current bridge instance whether HAP is enabled without needing to reach into server internals or duplicate bridge config logic.

Additional Context

The current asymmetry makes it harder for plugins to do the right thing when deciding whether to create or register HAP accessories versus Matter accessories for a given bridge instance.

This is especially relevant when dealing with:

• main bridge vs child bridge configurations
• bridge-specific enable/disable flags
• runtime behaviour that depends on the actual bridge state rather than plugin config alone

Because HAP is effectively the default transport and Matter is the opt-in transport, the API should expose both states consistently.

This is not a functional HAP bug; it is an API parity gap that affects plugin/platform development and bridge state awareness.