fix: start/pause values for T2117

[hfbauman]

I have a Robovac 25C (T2123) although it is recognized as T2117. Similarly to those in #303, I was having issues with the start button not starting, the pause button actually starting but not pausing, but the other buttons working fine. I did some digging and found that the values for the command lookup weren't populated properly, so I've fixed that in this PR.

[Copilot]

Pull request overview

Fixes incorrect START/PAUSE behavior for RoboVac models detected as T2117 by adding the missing boolean value mapping for the START_PAUSE command (DPS 2), aligning behavior with other boolean-toggle models referenced in issue #303.

Changes:

• Adds START_PAUSE command value mappings for T2117 (start -> True, pause -> False).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Add/extend unit tests to cover the new boolean START_PAUSE mapping for T2117 (e.g., assert getRoboVacCommandValue(START_PAUSE, "start") is True and "pause" is False). The repo already has per-model command mapping tests (see tests/test_vacuum/test_t2118_command_mappings.py:test_t2118_start_pause_values), but T2117 doesn’t appear to be covered yet, so this regression-prone behavior would benefit from a dedicated test file.

[hfbauman]

Start and pause are working, but returning to base no longer does... This seems to be due to a change made in #341, specifically this section:

robovac/custom_components/robovac/vacuum.py

Lines 789 to 793 in c602bed

	# For models with boolean START_PAUSE (e.g. T2128, T2276), DPS 2 is the
	# execution trigger — without it, the device ACKs but doesn't physically act.
	start_value = self.vacuum.getRoboVacCommandValue(RobovacCommand.START_PAUSE, "start")
	if start_value != "start":
	payload[self.get_dps_code("START_PAUSE")] = start_value

In particular, it seems that telling the vacuum to both pause and to return to base at the same time means that it just pauses. I will need to explore more to figure out how to keep compatibility with protocol v3.5.

@stevendejongnl, do you have any thoughts on this?