Remove legacy WPF app, flatten WinUI project to repo root, rename namespace

The repo carried two parallel UIs (WPF + WinUI) sharing Models/Services via
cross-directory Link includes. Now that WinUI is the only frontend, collapse
the structure so the WinUI project IS the repo root instead of a nested
sibling folder:

- Delete the WPF project entirely (App.xaml, MainWindow.xaml, csproj) and its
  bin/obj output
- Move AmiReel.WinUI/* up to the repo root (App, MainWindow, MainPage,
  DialogHelper, Assets, Package.appxmanifest, app.manifest, Properties,
  .github/instructions, AGENTS.md) via git mv, preserving history
- Rename AmiReel.WinUI.csproj -> AmiReel.csproj; regenerate the solution as
  AmiReel.slnx (the newer XML solution format) with a single project
- Rename namespace AmigaDB.VideoRenderer.{Models,Services} -> AmiReel.{...}
  and AmiReel_WinUI -> AmiReel across all files, including the embedded
  ffmpeg/ffprobe resource logical names in the csproj and ToolExtractor
- Models/ and Services/ no longer need the Link-based cross-directory
  <Compile Include>; they're picked up by the SDK's default globbing now
  that they live under the project directory
- Rename assets/ -> branding/ (source icon art) to avoid a case-insensitive
  collision with Assets/ (packaged tile art) once both sit at repo root
- Merge the two .gitignore files into one; track the PublishProfiles pubxml
  files instead of ignoring them (no secrets, and they keep publish
  reproducible across machines) as branding, gitignore, etc.
- Simplify publish-win-x64.ps1 (drop the -Target Wpf/WinUI switch, there's
  only one target now) and rewrite README.md to describe the single-project
  layout, build/run/publish commands, and file structure

Verified: dotnet build succeeds for both AmiReel.csproj and AmiReel.slnx, and
the built exe launches and renders identically to before the move.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.github/instructions/accessibility.instructions.md

@@ -0,0 +1,62 @@
+---
+description: 'Accessibility requirements for interactive controls, keyboard navigation, screen readers, and contrast'
+applyTo: '**/*.cs, **/*.xaml'
+---
+
+# Accessibility
+
+These rules apply to **every UI change**. They are not optional add-ons.
+
+---
+
+## Rules
+
+- **Every interactive control** must have an `AutomationProperties.Name` or `AutomationProperties.LabeledBy`.
+- Add a stable, unique `AutomationProperties.AutomationId` for controls targeted by UI automation tests (and for key interactive elements).
+- Use semantic XAML controls — prefer `Button`, `HyperlinkButton`, `ListView` over styled `Border`/`Grid` with click handlers.
+- Ensure **keyboard navigation** works for all features:
+  - Logical tab order via `TabIndex`.
+  - `AccessKey` bindings for frequently used actions.
+  - `KeyboardAccelerator` for shortcut keys.
+- Maintain **minimum contrast ratios** (4.5:1 for normal text, 3:1 for large text) — test in High Contrast mode.
+- Support **screen readers** (Narrator / NVDA): test that all content is announced correctly.
+- Images must have `AutomationProperties.Name` describing the image purpose (or `AutomationProperties.AccessibilityView="Raw"` for decorative images).
+- Do not rely on colour alone to convey meaning — add icons, text, or patterns.
+
+## Anti-patterns
+
+- Clickable `TextBlock` or `Image` without `AutomationProperties`.
+- Custom controls that are not keyboard-focusable.
+- Using `Visibility.Collapsed` to "hide" content from screen readers (use `AccessibilityView` instead).
+
+## Validation
+
+- Build & register the MSIX package — see **Build, Run & Deploy** in `.github/agents/Agents.md`.
+- Test keyboard navigation: tab through every new/changed UI area.
+- Test High Contrast: switch to Windows High Contrast theme and verify readability.
+- Run Accessibility Insights for Windows on the app.
+
+### Verification Checklist
+
+- [ ] All interactive controls have `AutomationProperties.Name`
+- [ ] Keyboard navigation works for the changed area
+- [ ] Tested with High Contrast theme enabled
+- [ ] Tab through the entire UI with keyboard only.
+- [ ] Verify key interactive controls have stable, unique `AutomationProperties.AutomationId` values (especially controls used by UI automation tests).
+- [ ] Switch to Windows High Contrast theme and verify readability.
+- [ ] Run Narrator and verify all controls are announced correctly.
+- [ ] Run **Accessibility Insights for Windows** on the app.
+
+## Must Read & Research
+
+> **Agent Rule:** Before any accessibility-related change, you **must** fetch and review these references using `fetch_webpage`. Apply what you learn.
+
+| # | Reference | When to consult |
+|---|---|---|
+| 1 | [Accessibility in WinUI](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/accessibility) | Any UI change — verify accessibility approach |
+| 2 | [AutomationProperties](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/basic-accessibility-information) | Adding or modifying interactive controls |
+| 3 | [Accessibility Insights](https://accessibilityinsights.io/docs/windows/overview/) | Testing tool — run before finalizing UI changes |
+| 4 | [Keyboard Accessibility](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/keyboard-accessibility) | Adding navigation, focus management, or shortcut keys |
+| 5 | [High Contrast Themes](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/high-contrast-themes) | Adding custom styles, colours, or theme resources |
+
+