[Feature]: winapp find-api check-file — validate the API references in a file before you build

## Is your feature request related to a problem? Please describe.

`winapp find-api check-property` validates one type's properties at a time. In practice, the thing a developer or agent actually wants to know is: **"does everything I just wrote in this file actually exist?"**

Today that means reading the file, extracting every type and member reference by hand, and issuing a batch of `check-property` / `members` calls. That's exactly the pattern we see: agents assembling large ad-hoc batches (20+ subjects in a single call) that are, in effect, a hand-rolled version of this command. It works, but it puts the burden of parsing the file on the caller, and it only happens when the caller remembers to do it.

The high-value moment is **before the build** — catching a hallucinated property or a misspelled enum value in a file you just wrote, without paying for a compile cycle.

## Describe the solution you'd like

A new verb that takes file paths and validates the Windows/WinRT API references inside them against the project's indexed metadata:

```bash
winapp find-api check-file MainWindow.xaml
winapp find-api check-file MainWindow.xaml MainWindow.xaml.cs ViewModels\ShellViewModel.cs
winapp find-api check-file MainWindow.xaml --json
```

- Batchable (N paths in one call), consistent with `search` / `members` / `enums` / `check-property`.
- Exits non-zero when any reference is confirmed missing, so it can gate a pre-build step or a CI check.
- `--json` for structured consumption.
- Language-agnostic name — deliberately **not** `check-xaml`. The same problem exists in C#, and eventually C++/IDL.

## Design constraint: only report a miss when we are certain we own the type

This is the make-or-break rule. One false positive on a user's own `MainViewModel` destroys trust in the command permanently. If a type cannot be confidently resolved to indexed Windows/WinRT metadata, it must be **silently skipped** — never surfaced as a warning, never counted toward the exit code.

That implies a tiered rollout by how syntactically certain each construct is:

| Construct | Certainty | Notes |
|---|---|---|
| `.xaml` attributes and attached properties | High | Namespace-qualified, unambiguous. Best starting point. |
| C# object initializers, `new T() { ... }` | High | Declared type is right there. |
| C# `Enum.Value` references | High | Enum type is named at the use site. |
| C# locals with an explicit declared type | Medium | Resolvable without full semantic analysis. |
| Arbitrary `foo.Bar` member access in C# | Low | Needs a Roslyn semantic model to know `foo`'s type. Out of scope for a first cut. |
| `.cpp` / `.idl` / `.ts` | Unknown | Not investigated. |

Suggested first increment: `.xaml` only, plus the high-certainty C# constructs. Ship the skip-when-unsure behavior from day one.

## Additional context

Follow-up to #652 (`winapp find-api`). Builds directly on the existing near-miss suggestion logic (`SimilarOnType`, `TypesWithProperty`, `TypesWithSimilar`) already used by `check-property` — this issue is mostly about the extraction layer in front of it, not new metadata work.