fix(agent-core): retry volatile DPI re-apply on cold boot

[iamshakibali]

What

Change the volatile-settings re-apply for first-sighted devices from one-shot to bounded-retry.

Why

The MX Master 3s is slow to enumerate after a reboot. The single confirming re-apply could time out against a still-booting mouse, so DPI (which lives in device RAM and clears on power cycle) reverted to the hardware default and stayed there until the next sleep/wake.

How

• reapply_followup changes from HashSet<String> (one confirm) to HashMap<String, u8> (retry budget per device key).
• New constant VOLATILE_REAPPLY_CONFIRM_RETRIES = 4 (~8s at the 2s inventory cadence).
• First-sighting devices keep getting re-applied until the budget exhausts.
• Reconnects/wake-from-sleep stay one-shot because the device is already booted.

Files

• crates/openlogi-agent-core/src/orchestrator.rs

Test

• 48/48 agent-core tests pass.
• New test plan_reapply_retries_a_first_sighting_for_a_bounded_run covers the decrement-and-exhaust path.
• clippy -D warnings + fmt clean.

[greptile-apps]

Greptile Summary

This PR upgrades the volatile-settings re-apply logic for cold-booted devices from a one-shot confirm to a bounded retry of VOLATILE_REAPPLY_CONFIRM_RETRIES = 4 additional writes (~8 s at the 2 s inventory cadence). The underlying cause is that the MX Master 3s can still be enumerating when the first HID++ DPI write arrives, silently losing it.

• reapply_followup changes from HashSet<String> to HashMap<String, u8>, carrying a per-device remaining-retry count that decrements each tick and is dropped when the budget reaches zero.
• First-sightings (new stable identity) receive the full retry budget; offline→online reconnects and system-wake re-applies stay one-shot, since the device is already booted in those cases.
• A new test plan_reapply_retries_a_first_sighting_for_a_bounded_run covers the full decrement-and-exhaust path.

Confidence Score: 5/5

Safe to merge. The retry logic is self-contained in plan_reapply, the budget drains correctly to zero, and offline/reconnect/system-wake paths are unaffected.

The HashSet to HashMap change is mechanically straightforward: the decrement-and-drain logic is correct, the mutual exclusion between the first-sighting block and the retry loop prevents any double-write or budget corruption within a tick, and the new test covers the full countdown path.

Files Needing Attention: No files require special attention. All changes are confined to the plan_reapply function and its test suite in orchestrator.rs.

Important Files Changed

Filename	Overview
crates/openlogi-agent-core/src/orchestrator.rs	Core retry logic change: HashSet to HashMap for followup budget, new VOLATILE_REAPPLY_CONFIRM_RETRIES constant, decrement loop in plan_reapply, and matching test coverage. Logic is internally consistent with no new bugs introduced.

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into fix/agent-cor..." | Re-trigger Greptile}