feat(homebridge-ring): add allowDisarm option to block disarm from HomeKit

[salmanesm]

feat(homebridge-ring): add allowDisarm option to block disarm from HomeKit

Closes #1651

Summary

Adds a new optional config flag, allowDisarm (default: true), to the Homebridge Ring plugin. When set to false, HomeKit Disarm requests are quietly blocked, while Arm Home/Away/Night continue to work as usual.

Why

Throwing an error from the .onSet handler produced a red error banner in the Home app / Siri, which was confusing even though the block was intentional. This change switches to a no-op + snap-back: the request is ignored and the Home app tile immediately reverts without an error toast.

What changed

• Config: allowDisarm?: boolean (default true, backward-compatible).
• security-panel.ts:
  • If state === DISARM and allowDisarm === false, log a warning, reset Target and Current state so the UI snaps back, and return early (no Ring API call, no thrown error).
• Docs: README updated with a config snippet.

Behavior

• allowDisarm: true → unchanged (HomeKit can arm & disarm).
• allowDisarm: false → Disarm is ignored; UI/Siri show no error; Ring remains armed.

Config example

{
  "platform": "Ring",
  "refreshToken": "<your-token>",
  "allowDisarm": false
}

[salmanesm]

Hi @dgreif — this adds an optional allowDisarm flag (default true).
When false, HomeKit “Disarm” is quietly ignored (no error toast), while arming modes still work.
Docs updated with a config example. Happy to adjust naming, default, or placement if you prefer!

[salmanesm]

Config used for validation: "allowDisarm": false
Expected behavior:
• Arm Home/Away/Night succeed
• Disarm is ignored (no error toast)
• Log: [Ring Alarm] Disarm attempt from HomeKit blocked (allowDisarm=false)
Implementation resets both TargetState and CurrentState so the Home app stays in sync.

[dgreif]

Thanks for the PR @salmanesm! I see the error banner as a "feature", not a bug. What are the scenarios where you expect a disarm to fail and are ok with it?