[Fabric][Composition] Expose a non-mutating focusability API on ComponentView (e.g. IsFocusable ) for FocusZone / single-tab-stop scenarios

[srividyaramas]

Problem Description

Building a FocusZone / single-tab-stop control on Composition (New Architecture) requires identifying the next focusable  ComponentView  in tab order. Today there is no non-mutating way to test whether a  ComponentView  can take focus, so we must call  ComponentView.TryFocus(...)  in a loop — which moves focus as a side effect while probing. We need a query API that reports focusability without changing focus.

What we're doing
Native  RCTFocusZone  implementation. On Tab we want to move focus to the first focusable element outside the zone in one transition; arrow keys navigate within. To find that element we DFS the tree and call  TryFocus  on each candidate until one succeeds, because there's no way to ask "is this focusable?" first.
Gaps

1. No non-mutating focusability property on  ComponentView . Requesting an  IsFocusable  /  Focusable  (get-only  bool ) property, so we can select the correct target without side-effecting focus.
2.  Composition.FocusManager.FindFirstFocusableElement  /  FindLastFocusableElement  statics throw — their activation factory ( IFocusManagerStatics ) isn't registered in the runtime we load, so  get_activation_factory  throws (fatal inside a  noexcept  input handler). If these are the intended API, they need to be usable from a hosted RNW app.
3.  GettingFocusEventArgs.TrySetNewFocusedComponent(ComponentView)  projects as  void  (no success  bool ), so we can't redirect focus during  GettingFocus  and know whether it was accepted, forcing focus logic into  KeyDown  instead.
   Ask
   Primarily (1) a non-mutating focusability query on  ComponentView . Secondarily, clarify/fix (2) and (3) so focus navigation can be built without trial-and-error  TryFocus .
   Workaround
   DFS +  TryFocus  trial-and-error in  KeyDown , which mutates focus while probing and costs a tree walk per keystroke.

Steps To Reproduce

1. In a react-native-windows Fabric (Composition / New Architecture) app, add a native
   component (e.g. a custom FocusZone) that subclasses the codegen ComponentView and, in
   Initialize, registers a KeyDown handler on the container ComponentView.
2. In that handler, try to move keyboard focus to the next focusable ComponentView in tab
   order (e.g. on Tab, the first focusable element outside the zone). To do this you must
   determine which ComponentView can accept focus.
3. Look for a non-mutating way to test whether a given ComponentView is focusable. There is
   none: ComponentView.TryFocus(FocusState) is the only option, and it moves focus as a
   side effect while probing.
4. Result: you have to call TryFocus in a loop across candidate views, causing focus to
   actually move during probing, and there is no API to identify the correct target up front.

Expected Results

No response

CLI version

CLI version is  13.6.9

Environment

react-native-windows 0.81.5 (Fabric / Composition),  Microsoft.ReactNative  C++/WinRT

Community Modules

No response

Target React Native Architecture

None

Target Platform Version

None

Visual Studio Version

None

Build Configuration

None

Snack, code example, screenshot, or link to a repository

No response