Extract KeyboardNodesPolicy for keyboard routing decisions

[enaboapps]

Problem

"Which scanner gets these nodes" / "should we rebuild the scan tree" rules are scattered across four files:

File	Rule
NodeExaminer.kt:92	Use keyboard root if isKeyboardVisible(windows)
ActiveAccessTechnique.kt:47	Use keyboard scanner if isVisible && !isEscaped && technique != MENU
ActiveAccessTechnique.kt:253-262	onKeyboardStateChanged tears down/builds scanners
BaseNodeScanner.isDuplicateUpdate	Bounds-equality dedup at the wrong level

The conditions are subtly inconsistent — currentAccessTechnique excludes MENU mode but cleanupAllExceptKeyboard does not. The MainMenuStructure rebuild fix in #2001 had to chase a similar inconsistency.

Proposal

Mirror what #1999 did for the prompt with KeyboardSelectionPolicy: extract a KeyboardNodesPolicy class with the routing/rebuild decisions as pure functions of KeyboardState (and KeyboardNodesState once #2249 lands).

class KeyboardNodesPolicy {
    fun shouldRouteToKeyboardScanner(state: KeyboardState, currentTechnique: String): Boolean
    fun shouldRebuildScannerFor(prev: KeyboardState, next: KeyboardState): Boolean
    fun shouldDropAsStale(nodes: KeyboardNodesState, state: KeyboardState): Boolean
}

All three callsites delegate; the rules become unit-testable in isolation.

Files

• New: app/src/main/java/com/enaboapps/switchify/service/keyboard/KeyboardNodesPolicy.kt.
• app/src/main/java/com/enaboapps/switchify/service/techniques/ActiveAccessTechnique.kt — currentAccessTechnique getter and onKeyboardStateChanged delegate to the policy.
• app/src/main/java/com/enaboapps/switchify/service/techniques/nodes/scanners/BaseNodeScanner.kt — bounds-equality dedup moves into the policy.
• New: app/src/test/java/com/enaboapps/switchify/service/keyboard/KeyboardNodesPolicyTest.kt.

Verification

• New unit test covers each policy rule across visible / escaped / menu permutations.
• Existing item-scan ↔ keyboard-scan transitions behave identically on device.

Related

• Depends on NodeExaminer: read keyboard visibility from KeyboardManager (single source of truth) #2248 (consistent visibility source) for the routing rule to be coherent.
• Depends on Promote keyboardNodesFlow to StateFlow<KeyboardNodesState> with bounds + revision #2249 for the shouldDropAsStale rule to have bounds to compare against.