Phase 3c: Subscriptions — setNotifyValue, intent, re-arm

[itsniper]

Parent: #52

Requirements

• Subscribe/unsubscribe via platform setNotifyValue only—never write CCCD 0x2902 directly (FR-10.4.1).
• Confirm callback before active; sequence enable before notify-producing work (FR-10.4.2).
• Expose subscription state; don't trust isNotifying alone (FR-10.4.3).
• Track subscription intent; re-arm after reconnect, restore, didModifyServices (FR-10.4.5).

Lifecycle interactions (from #51)

• Subscription intent is not link demand. Decide explicitly whether an active subscription keeps a link alive. A notify-only integration (FR-4.2.1) that subscribes and then goes quiet will otherwise be idle-disconnected after 5s, which silently breaks it. If intent should suppress idle, it must register as demand alongside work leases and manual-connect holds; if not, document that notify-only consumers must hold a manual connect.
• Re-arm must run inside the discovery gate. Re-arming happens after re-discovery reaches ready, on a link that may itself have been re-established by Tier-0, the Tier-1 ladder, or a radio-return sweep. All three converge on the same ensure-linked path, so re-arm hooks the ready transition, not any individual reconnect trigger.
• Persisted intent scope. Manual-connect holds are the only durable, cross-relaunch demand. If subscription intent should also survive relaunch for restored peripherals (FR-10.6.3), that is a second persisted store and needs its own decision; otherwise intent is process-scoped and restoration re-arms only what the app re-declares.

Acceptance criteria

• Public subscribe API on Peripheral
• Intent survives reconnect/restore/modify paths (or explicit inactive reporting)
• Relationship between subscription intent and idle teardown decided, documented, and tested
• Tests for enable confirm + re-arm