[Feature]: winapp run --devtools: in-app inspector and shared design-time protocol

**Depends on:** project-mode run support (#633)

## Summary

Add `winapp run --devtools` so a WinUI app can be launched with an in-app developer toolbar and a shared protocol for live inspection and editing.

This is the first deliverable in the design-time lane: a lightweight, F12-style devtools surface with a live visual tree, property inspection, and supported element/property updates while the app is running. The protocol must be shared so VS Code, GitHub Copilot, and other extensions can connect to the same running app later.

## Problem

Today WinUI apps can be run from the CLI, but once the app is running there is no common, editor-agnostic way to inspect the live tree or edit elements in place. Visual Studio has pieces of this experience, but the modern outer-loop surfaces — VS Code, Copilot, and other extensions — need a first-class runtime channel.

Without a shared protocol, every surface would reinvent its own attachment story and the design-time experience would fragment again.

## Goals

- Add `winapp run --devtools` as an opt-in launch mode
- Provide an in-app devtools toolbar / overlay similar to F12 browser tools
- Expose a live visual tree and property inspector for the running app
- Allow supported element/property edits while the app is running
- Define a stable, shared protocol that editor and agent clients can reuse

## Non-goals

- Building the full XAML designer or visualizer here
- Solving hot reload end-to-end (tracked separately)
- Replacing `winapp ui` or UI automation commands
- Shipping a full Visual Studio feature clone
- Making this a general-purpose remote app-debugging protocol for non-WinUI apps

## Proposed behavior

### Launch mode

- `winapp run --devtools ` should launch the app with devtools enabled.
- The running app should surface a lightweight toolbar or overlay that lets the developer open the live inspection surface.
- The launch path should still honor the project-mode run pipeline for build, launch, runtime install, and diagnostics.

### Devtools surface

- Initial surface:
- live visual tree
- element selection / highlighting
- property inspection
- supported property editing
- The experience should feel like F12 devtools, not a separate IDE.
- The tooling should be usable by both humans and agents.

### Shared protocol

- Define a versioned protocol for attaching to the running app and querying/modifying UI state.
- The protocol should support at least:
- enumerate tree
- inspect node properties
- select / highlight element
- update supported properties
- receive live-change notifications
- Transport should be local-first and hidden behind the protocol contract so clients are not tied to one implementation.

## Key implementation constraints

- The protocol must be stable enough for external clients to build against
- Keep the runtime attach surface opt-in and development-only
- Avoid coupling the protocol to a single editor or agent host
- Keep `winapp ui` separate; this is in-app inspection, not external UI automation
- Preserve the ability to grow this into the broader design-time engine later

## Migration path

1. `winapp run --devtools` becomes the first public entry point to the protocol.
2. VS Code, GitHub Copilot, and other extensions can then consume the same protocol for live tree inspection and property editing.
3. The protocol and runtime host can later become the foundation for the broader design-time engine that also powers the designer and other surfaces.

## Success criteria

- A developer can launch a WinUI app with `--devtools` and inspect the live UI while it runs
- The toolbar/overlay makes the devtools surface discoverable without Visual Studio
- The protocol supports at least tree inspection and property editing from an external client
- The same protocol can be reused by future editor and agent integrations

## Risks / watchouts

- Security and attach control matter even for local-only tooling
- Live inspection can be expensive if the protocol is too chatty
- If the protocol is not versioned early, clients will break as the surface evolves
- The in-app surface can easily drift into a partial designer if the scope is not kept tight

## Why this matters

This is the first step toward a real, shared design-time story for WinUI: one running app, one protocol, many clients.