fix(devices): route mutation PUTs to /2.3 endpoint (partial fix for #102)

[ff-renovate]

Partially closes #102.

Summary

Device-mutation PUTs on /2.2/networks/{id}/devices/{id} are silently no-ops — the Eero backend returns 200 OK but the change never persists. The /2.3/ endpoint processes the same PUT correctly.

Adds DEVICE_UPDATE_ENDPOINT = "https://api-user.e2ro.com/2.3" and a private _update_device() helper. All four device-mutation methods now build absolute 2.3 URLs; reads and all other resources continue to use the 2.2 base URL.

What this actually fixes (verified live)

Tested against a real account, this branch vs master:

Method	On master (2.2)	On this branch (2.3)
pause_device	200 OK, paused unchanged	✅ Persists (round-trip via get_device)
set_device_nickname	200 OK, nickname unchanged	✅ Persists (round-trip via get_device)
set_device_priority	200 OK, no state change	❌ Still no state change — see #111
block_device	200 OK, no state change	❌ Still no state change — see #109

What this does NOT fix — separate follow-ups

Verification against a real account revealed that two of the four "silent no-op" mutations are broken for a different reason than the 2.2/2.3 version drift — the payload / field mapping is wrong. These need their own investigation and are being tracked separately:

• [Bug]: block_device() is a silent no-op — wrong field, wrong endpoint (not fixed by #108) #109 — block_device sends {blocked: bool} but the device object has no blocked field (the real field is blacklisted, and blocking uses the dedicated /networks/{id}/blacklist endpoint).
• [Bug]: set_device_priority is a silent no-op — device object has no prioritized field #111 — set_device_priority sends {prioritized: bool} but the device object has no prioritized field at all.
• [Bug]: BlacklistAPI.add_to_blacklist sends {device_id} — API rejects with 400 "mac required" #110 — related BlacklistAPI.add_to_blacklist bug (wrong payload shape: device_id vs mac).

Third-party corroboration

The 2.2 → 2.3 device-write drift has been independently reported by three other Eero clients, all with the same fix:

• erikh/eero#1 (Rust)
• dciobanu/eero-cli#2 (Go)
• dougschaefer6/swamp-eero (Python) — includes an explicit code comment noting "some endpoints use 2.3"

Tests

Adds v2.3 URL-targeting assertions to all four device-mutation tests in tests/api/test_devices.py. All existing tests pass; CI green after the Black fixup commit.

Follow-up refactor (deferred, not blocking)

Discussion during review flagged that a (host, version) split of the endpoint constants could ergonomically handle future drift. Not scoped here — one data point isn't enough to justify the refactor. Full proposal + trigger conditions logged in .claude/docs/api-endpoint-versioning.md.

---

Original draft opened by the draft-fix workflow; fixup + live-verification + honest scoping done in the current session.

[ff-renovate]

🎉 This PR is included in version 5.0.12 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀