Set version to 0.6.0 for release

Run39 migration baseline: CLI mechanical migration and orientation gu…

…idance

Set version to 0.5.0 for release

Set version to 0.4.0 for release

fix(ui): report ambiguity on partial process name match (#564)

When multiple processes match a partial `--app` query (e.g. `-a
terminal` matching two `WindowsTerminal` instances) and all have visible
windows, the code silently fell through to title search which then
failed with a misleading *No running app found* error.

Now it throws a clear error listing the matching PIDs, process names,
and window titles — consistent with the exact-name-match path:

```
Multiple processes matching 'terminal' found:
  PID 6816 (WindowsTerminal): ...
  PID 10516 (WindowsTerminal): Administrator: Windows PowerShell
Use --app with a PID or a more specific window title.
```

Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

ci(metrics): post PR metrics comment from a workflow_run job (fixes f…

…ork PRs) (#514)

## Why
PR builds from forks (e.g. #506) are failing the `build-and-package` job
because the in-build *Report build metrics* step tries to POST a PR
comment, but `GITHUB_TOKEN` is silently downgraded to read-only for the
`pull_request` event when the head repo is a fork — so the API returns
`403 Resource not accessible by integration` and the build is marked
failed even though build/test/package all succeeded.

## What
Move the comment-posting out of the build into a separate
`workflow_run`-triggered workflow that runs in the base repo context
with full token write access. Same fix pattern applied to
`mark-metrics-stale` (now on `pull_request_target`).

### Files

| File | Change |
|---|---|
| `.github/actions/report-metrics/action.yml` | Removed comment-posting
step; now stages current+baseline JSONs into a `metrics-data` artifact.
|
| `.github/workflows/post-metrics-comment.yml` (new) | Triggered on
`workflow_run` of *Build and Package*. Downloads `metrics-data`, builds
+ posts/updates the PR comment. |
| `.github/workflows/mark-metrics-stale.yml` (new) | Same job that lived
in build-package.yml, now on `pull_request_target` so fork PRs also get
write perms. |
| `.github/workflows/build-package.yml` | Removed `mark-metrics-stale`
job (relocated). |

## Security
The `metrics-data` artifact is produced by code from the PR (potentially
untrusted). The privileged `workflow_run` workflow treats it
accordingly:

- **PR identity is never trusted from the artifact.** The PR number is
resolved from the trusted `workflow_run.head_sha` via
`listPullRequestsAssociatedWithCommit` and verified against the PR's
current head.
- **head_sha + run id in the footer come from `workflow_run` metadata**,
not the artifact.
- **All metric values are coerced + range-checked**; binary-size keys
are filtered against an allowlist with no fallback rendering — a
malicious build can't inject Markdown, links, mentions, or HTML into the
bot-authored comment.
- **Gated on `workflow_run.conclusion == 'success'`** so failed builds
can't overwrite a previously good metrics comment with partial data.
- **Comment lookup is paginated** so the existing comment is reliably
found on noisy PRs.

## Validation
- YAML parses (`yaml.safe_load`).
- Inline JS body parses (`node --check`).
- The actual fork-PR scenario can only be verified end-to-end after
merge — once merged, re-running #506's build will exercise both new
workflows.

## Follow-ups (out of scope here)
- Consider adding `concurrency: pr-N` to `post-comment` so out-of-order
`workflow_run` arrivals on rapid pushes can't race the comment update.

---------

Co-authored-by: Nikola Metulev <711864+nmetulev@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

test(e2e): handle experimental runtime package name in PackageShouldI…

…ncludeRuntimeDependency

The expected Microsoft.WindowsAppRuntime package name was derived as
'.{major}.{minor}', which only matches stable (1.x) packaging. Experimental
2.x ships as 'Microsoft.WindowsAppRuntime.{major}-experimental{N}' (no minor,
with the suffix). When the experimental feed bumped to -experimental7 the
test started asserting an outdated stable-style name against the actual
experimental dependency in the MSIX.

Detect the -experimental suffix in the SDK version and build the expected
runtime name accordingly. Test-only change.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix build

fixing release pipeline

Bumped version to 0.1.10