Fix RFBridge button overrides being coerced into binary sensors

[elizarov]

RFBridge per-button YAML overrides support setting device_class: button so learned RF codes can be exposed as Home Assistant button entities instead of sticky binary_sensor entities. In practice this override did not work for remote_type 6 entries (the RFBridge channels that eWeLink reports as alarm-style remotes), even when the YAML was loaded correctly and the entity names matched. The integration kept recreating those entities as binary sensors.

I've found it when I added this to configuration.yaml but nothing changed, my buttons were still exposed as binary sensors:

sonoff: 
  rfbridge:
    Button A:
      device_class: button

The root cause was in config validation rather than in the RFBridge runtime mapping itself. The rfbridge schema assigned a default timeout of 120 seconds to every configured child entry, including entries that only specified device_class: button. Later, the RFBridge entity builder treats any child that has a timeout or payload_off as sensor-like and removes the button classification. As a result, a user-provided device_class: button override was silently converted back into the binary-sensor code path before entities were created.

Fix this by removing the schema-level default for rfbridge timeout. Timeout remains optional in YAML, and the runtime code continues to apply its existing default timeout only for actual XRemoteSensor entities. This preserves the intended behavior for sensor/alarm configurations while allowing device_class: button overrides to survive schema parsing and be honored for RFBridge children.

Also add a regression test that validates a minimal rfbridge override with device_class: button does not gain an implicit timeout during schema validation and produces an XRemoteButton for a remote_type 6 RFBridge child. This protects the exact user-facing scenario where changing the entity type in YAML previously had no effect.