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/security.instructions.md

@@ -0,0 +1,55 @@
+---
+description: 'Security requirements for secrets management, input validation, permissions, and secure coding'
+applyTo: '**/*.cs, **/*.appxmanifest'
+---
+
+# Security
+
+These rules apply to **every feature and change**. They are not optional add-ons.
+
+---
+
+## Rules
+
+- **Never hard-code secrets** (API keys, passwords, connection strings) — use environment variables, Windows Credential Manager, or Azure Key Vault.
+- Validate and sanitize **all external input** (user input, file content, network responses).
+- Use `SecureString` or `PasswordVault` for sensitive data in memory when practical.
+- Follow the **principle of least privilege** — request only the permissions the app actually needs in `Package.appxmanifest`.
+- Keep NuGet packages up to date — run `dotnet list package --outdated` regularly.
+- Enable **code signing** for published MSIX packages. Use the `winapp` CLI rather than hand-rolling `signtool`:
+  - Generate a development certificate matching the manifest publisher: `winapp cert generate --manifest .\Package.appxmanifest --install`.
+  - Inspect a cert before signing: `winapp cert info .\devcert.pfx`.
+  - Sign an existing file: `winapp sign .\MyApp.msix --cert .\devcert.pfx`.
+  - Build + sign in one step: `winapp pack .\bin\<Platform>\Release\<TFM>\win-<rid> --cert .\devcert.pfx`.
+  - Production releases must be signed by a trusted certificate authority -- never ship the development cert.
+- When using `HttpClient`, always validate TLS certificates and use HTTPS.
+- Never log sensitive data (PII, tokens, passwords).
+
+## Anti-patterns
+
+- Storing secrets in `appsettings.json` committed to source control.
+- Disabling TLS validation for debugging and forgetting to re-enable it.
+- Using `Process.Start` with unsanitized user input.
+- Broad `try { } catch (Exception) { }` that swallows errors silently without any logging.
+
+## Validation
+
+- Build & register the MSIX package — see **Build, Run & Deploy** in `.github/agents/Agents.md`.
+- Check for hard-coded secrets: search for `password`, `apikey`, `secret`, `connectionstring` in `.cs` files.
+
+### Verification Checklist
+
+- [ ] No secrets are hard-coded
+
+## Must Read & Research
+
+> **Agent Rule:** Before any security-related change (auth, input handling, permissions, HTTP), you **must** fetch and review these references using `fetch_webpage`. Apply what you learn.
+
+| # | Reference | When to consult |
+|---|---|---|
+| 1 | [.NET Security Best Practices](https://learn.microsoft.com/en-us/dotnet/standard/security/) | Any code handling credentials, tokens, or sensitive data |
+| 2 | [Secure coding guidelines for .NET](https://learn.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines) | Input validation, exception handling, type safety |
+| 3 | [MSIX Security](https://learn.microsoft.com/en-us/windows/msix/msix-container) | Packaging, signing, or distribution changes |
+| 4 | [Package.appxmanifest capabilities](https://learn.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations) | Adding or modifying app capabilities/permissions |
+
+