bug(linux/wayland): la ventana no se puede posicionar: tira centrada, arrastre y cambio de monitor inoperativos

Start from Widget.tsx:831 where getCurrentWindow().setPosition is called and detail_geometry.rs:56 where initial anchoring uses window.set_position. Reproduce under Wayland with npm run app:dev on GNOME, confirm window stays centered. Done means window docks to dockEdge and drag works, or app explicitly declares Wayland limitation.

Pre-flight checks

• I searched existing issues and found no duplicate.
• I understand that this report enters review before implementation.

What happened?

Bajo sesión Wayland nativa la ventana del widget no se puede colocar en ningún
punto de la pantalla. Se observan tres síntomas con una sola causa:

1. La tira queda centrada en la pantalla en lugar de anclarse al borde
   configurado (dockEdge: "right"), y no se reposiciona nunca.
2. El arrastre no mueve la ventana: el gesto se registra (el cursor cambia a
   grabbing), la aritmética interna calcula la nueva coordenada, pero la
   ventana no se desplaza.
3. No hay forma de llevar el widget a otro monitor (probado con una segunda
   pantalla): el arrastre tampoco cruza, y Settings.tsx no expone ningún
   selector de monitor (grep de dockMonitor en Settings.tsx sin resultados;
   el campo existe en config.json y solo lo escribe el widget al acoplar).

Consecuencia funcional: en Wayland el widget no cumple la premisa de estar
dockeado a un borde. Las mitigaciones que muestra «Ajustes › Sesión de
escritorio» no pueden aplicarse (ver detalle técnico abajo).

Steps to reproduce

1. Ejecutar Quorb desde main en una sesión Wayland nativa
   (XDG_SESSION_TYPE=wayland), p. ej. Ubuntu 26.04 con GNOME (Mutter).
   Lanzamiento: npm run app:dev.
2. Observar que la tira aparece en el centro de la pantalla, no en el borde
   derecho (dockEdge: "right", dockOffset: 0.742).
3. Pulsar el asa de arrastre y arrastrar: el cursor cambia a grabbing, pero la
   ventana no se mueve (mismo síntoma que el punto 4 de #168, acá en GNOME).
4. Conectar una segunda pantalla y arrastrar hacia ella: tampoco llega.
5. En Ajustes no existe opción para elegir la pantalla destino.

Expected behavior

1. La tira se ancla al borde configurado, o la app declara explícitamente que el
   anclaje no está disponible en este compositor y ofrece la alternativa real.
2. El arrastre mueve la ventana y al soltar se imanta al borde más cercano
   (comportamiento verificado y funcional bajo X11).
3. Existe una vía (selector en Ajustes o arrastre) para elegir el monitor
   destino, o su ausencia queda declarada en el bloque de compatibilidad.

Environment

OS: Ubuntu 26.04.1 LTS (Resolute Raccoon), x86_64
Session: XDG_SESSION_TYPE=wayland, XDG_CURRENT_DESKTOP=ubuntu:GNOME (Mutter)
Toolkit: WebKitGTK 2.52.6 (Tauri 2, tao 0.37.1, GTK 3.24.52)
Quorb: main @ 404dca5 (post #169), ejecutado con `npm run app:dev`
Config: dockEdge=right, dockOffset=0.742, autoHide=true, alwaysOnTop=true

Affected area

Application behavior

Agent or client (for MCP or headless incidents)

No response

Shell (for MCP or headless incidents)

No response

---

Anexo: detalle técnico

La cadena hasta la causa raíz

Cadena completa verificada en el código de esta revisión:

Widget.tsx:831   getCurrentWindow().setPosition(new PhysicalPosition(x, y))   ← arrastre
detail_geometry.rs:56   window.set_position(...)                             ← anclaje inicial (set_widget_bounds)
        ↓
tao 0.37.1  platform_impl/linux/window.rs:472   set_outer_position → WindowRequest::Position
        ↓
tao 0.37.1  platform_impl/linux/event_loop.rs:301   window.move_(x, y)
        ↓
GTK3  gtk_window_move()   →  SIN EFECTO bajo Wayland (documentado por GTK: solo opera en X11)

Es decir: el cálculo de posición funciona, el envío funciona, y la primitiva
final es un no-op en Wayland. Por eso #169 (que arregló el origen de la
aritmética del arrastre, que usaba outerPosition() = (0,0)) no alcanza para
que la ventana se mueva: falta el lado de salida.

Relación con issues existentes (no es duplicado)

• #168 (abierta, KDE/Wayland): su punto 4 es «arrastrre congelado» y su
  análisis de causa raíz atribuye el síntoma al origen falso outerPosition()
  = (0,0). El fix correspondiente ya está en main (líneas 796-826 de
  Widget.tsx usan widgetBounds como origen) y el síntoma persiste en
  GNOME: la causa restante es la de este reporte (salida no-op). Evidencia
  complementaria, no duplicado.
• #179 (abierta, X11/XWayland sobre KDE): mide que bajo X11 el arrastre sí
  transporta la ventana (406×270 px medidos) y solo fallan los márgenes
  finales. Eso es el contrapunto experimental: mismos archivos de
  arrastre/geometría que main, y el fallo solo aparece en el backend Wayland.
• #113 (abierta, feat): dock al monitor principal y aviso de monitor
  externo. Comparte el terreno de «monitor» pero es una mejora de elección de
  monitor, no la imposibilidad de mover la ventana.
• #147 (cerrada, fix): recuperación de posición/natur corruptos; no cubre
  posicionamiento inicial bajo Wayland.

Límites honestos de esta medición

• Medido en GNOME/Mutter; KDE no se probó en esta sesión (el arrastre bajo
  X11/XWayland en KDE sí está medido en #179).
• La app se ejecutó desde npm run app:dev (binario debug); no se probó el
  .deb/AppImage instalado en esta ronda.