Add unit tests, dedupe FFmpeg output filtering, harden settings records

Implements the suggestions from the last review pass:

- Add AmiReel.Tests (MSTest), covering the pure logic in Models/ and
  Services/: SupportedVideoFormats, AppSettings normalization,
  UserFacingErrors.Summarize, the new FfmpegProgressParser/
  FfmpegOutputFilter, RenderPipeline.Validate, BuildProgressMessage, and
  MoveSourceVideos. 59 tests, all passing. UI code-behind and anything that
  spawns an actual FFmpeg process are left to manual/integration testing.
  Exclude AmiReel.Tests\**\*.cs from AmiReel.csproj's default item glob —
  it's a subfolder of the app project now, so without the exclude the app
  itself was compiling the MSTest-only test files.

- Extract the FFmpeg version/library-banner boilerplate list that
  ProcessRunner (live log filter) and UserFacingErrors (error summarizer)
  had each duplicated into a shared FfmpegOutputFilter.IsBoilerplateLine;
  each caller keeps its own remaining context-specific checks on top.
  Also extract ProcessRunner's line-parsing regexes into a standalone
  FfmpegProgressParser so it's directly unit-testable without spawning a
  process.

- Convert AppSettings and RenderSettings from positional record
  constructors to named `required` init properties. Both records had
  runs of same-typed consecutive parameters (three string timing fields
  in AppSettings; three doubles then five ints in RenderSettings) that a
  positional constructor would let get silently transposed at a call site
  without the compiler catching it. Update the two call sites
  (MainPage.xaml.cs) to object-initializer syntax.

- Add Properties/AssemblyInfo.cs with InternalsVisibleTo("AmiReel.Tests")
  and make Validate/BuildProgressMessage/IsNoise internal so tests can
  reach them directly instead of only through process-spawning entry
  points.

- README: document `dotnet test`, and note that Package.appxmanifest's
  Identity is a local-dev placeholder that needs a real publisher/cert
  before MSIX distribution.

Verified: dotnet build (solution + test project) is 0 warnings/errors,
dotnet test is 59/59 passing, and the app still launches unchanged.

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

README.md

@@ -74,6 +74,19 @@ dotnet build .\AmiReel.csproj
 dotnet run --project .\AmiReel.csproj
 ```
 
+## Run Tests
+
+Unit tests live in `AmiReel.Tests/` (MSTest), covering the pure logic in `Models/` and
+`Services/` — settings normalization, supported-format detection, FFmpeg output parsing/
+filtering, render-settings validation, and moving source files into `originals/`.
+
+```powershell
+dotnet test .\AmiReel.Tests\AmiReel.Tests.csproj
+```
+
+UI code-behind (`App`, `MainWindow`, `MainPage`) and anything that spawns an actual FFmpeg
+process are intentionally left to manual/integration testing rather than unit tests.
+
 ## Publish
 
 ```powershell
@@ -141,6 +154,10 @@ successful render.
   attribution required by that distribution.
 - Windows Explorer may cache executable icons. If a freshly published build still shows an old
   icon, rename the file or refresh the icon cache before assuming the embed failed.
+- `Package.appxmanifest` currently has a placeholder `Identity` (a random GUID `Name` and
+  `Publisher="CN=AppPublisher"`). That's fine for local unpackaged builds, but before signing
+  an MSIX for real distribution, replace them with a real publisher identity and generate a
+  matching signing certificate (`winapp cert generate`, see `AGENTS.md`).
 
 ## Troubleshooting