Raise the child-window (spatial window) cap for Meta VR Layout SDK apps?

 Hi — this is a feature request rather than a bug report.

Short version: could the Layout SDK's child/spatial-window cap on device be raised, or
made configurable? Today a plain Android app wrapped in SpatialScene can keep two child
windows placed; a third one never gets a slot.

Context from a real project
I'm adding companion panels to an Android reader app on Quest 3: a page thumbnail panel on
the left, a transport/progress bar at the bottom, and the reader's settings stack on the
right. Three small surfaces, one main window, all declared as SpatialWindow children of a
single SpatialScene with distinct priorities.

In Meta Spatial Simulator all three place and the layout works.

On device the third stays in
WindowLifecycle.Pending forever while the other two are Active — and closing either of them
makes the third place immediately. So the app-side behaviour is correct; it's purely the
number of slots.

I can see this is deliberate rather than a defect — VwmError.PolicyViolation (-7) maps to
VwmFailureClass.Capacity, described as "the child-window cap (a system policy)", and the
best-practices page recommends "one main window and no more than two simultaneously
important spatial windows". So I'm not asking you to fix anything. I'm asking whether that
cap could be raised, or exposed, for apps that genuinely need three or four compact
companion surfaces.

Why three helps here
These aren't three equally-important apps side by side — it's one main window plus compact
controls. Two of them (the thumbnail rail and the settings stack) target the same screen
edge, so I made them mutually exclusive to fit the budget. That works, but it costs the
user: you can't browse the page list and change a setting at the same time. A slightly
larger budget would remove that compromise.

Asks, in order of preference
1. Raise the cap on device (even just to match the Simulator's three), or make it
   opt-in/configurable for apps whose windows stay small.
2. If the cap has to stay, please document the device-side number. The only figure
   published today is the Simulator's ("The Simulator supports up to three spatial
   windows"), which reads as if it applies everywhere — we designed and tuned a
   three-panel layout in the Simulator that could never have worked on device.
3. Expose remaining capacity at runtime. WindowLifecycle.Pending currently means both
   "waiting for a lower-priority window to be preempted" and "there is no room and there
   never will be", so an app can't tell "wait" from "give up" and adapt (e.g. merge panels).

Environment, in case it helps
- Quest 3 (eureka), Android 14, build UP1A.231005.007.A1, ro.vros.build.version = 209
- com.meta.metavrx.layout:layout-compose-compat:1.0.0, layout-window-compose-compat:1.0.0
- Plain Android app (Jetpack Compose), non-immersive, wrapped in SpatialScene

Logcat (our tag, printing WindowState.lifecycle):
  window 'reader_pages'     -> Active
  window 'reader_transport' -> Active
  window 'reader_settings'  -> Pending