feat: add core ZeoApi with ZeoCommandTrait and ZeoFeatureTrait

[NOisi-x]

Builds on #895
Closes #833

What this PR does

Finally, this PR gives us the ability to really start a wash programe on Zeo devices.

What you can now do

device.zeo.command.start_program()   # Start washing with current settings
device.zeo.command.pause()           # Pause mid-cycle
device.zeo.command.resume()          # Continue after pause
device.zeo.command.shutdown()        # Power off

The start command reads the device's current mode, program, temperature, rinse, spin, and drying settings via the MQTT cache — no extra network round-trip if the values were already pushed. It bundles everything together and sends it as one MQTT message, the same way the official app does.

How it knows what the device supports

ZeoFeatureTrait does two things at connection time:

1. Product type detection — looks at the model ID (e.g. roborock.wm.a234) and immediately knows whether it's a dryer or a specific washer series. No device query needed, this info is static per model.

2. Feature discovery — queries DP 237 once and parses a 24-bit capability mask into readable flags like smart_hosting, ion_deodorization, wash_dry_linkage. These flags control which optional DPs get included in start commands.

RoborockZeoProtocol additions

• UNKNOWN_246 = 246 — placeholder to prevent "unknown code" errors if a device reports this protocol number
• UNKNOWN_259 = 259 — same; reserved protocol slot, not found in the plugin bundle

[allenporter]

Great work articulating the differences between the washer and dryer. Given the differences (e.g. params, modes, etc). This seems like a perfect use for separate traits. It seems like a "washer trait" and "dryer trait" now make sense to introduce.

Can you review the existing trait pattern for prior art?

[NOisi-x]

@allenporter The difference between washer and dryer in ZeoCommandTrait is just the start parameter list — 10 DPs vs 7 DPs. Everything else (start_program, pause, resume, shutdown, cache checking, feature gating) is identical since they are all Zeo devices. Splitting into two classes would duplicate ~95% of the code.

V1's CommandTrait serves the same role for vacuums with vastly different dock types (pure collect vs collect+wash+dry+plumbing) — all through a single trait. The is_dryer flag here is equivalent to V1's dock_features check: resolved once at construction, not at runtime.

Given the minimal difference, is the current single-trait approach acceptable, or would you still prefer separate classes?