fix: make JobLogger thread-safe

[negativeeddy]

What

Fixes code-review item #2 — Fix JobLogger thread-safety.

JobLogger wraps a StreamWriter, which is not thread-safe. Concurrent Log<TState> calls from multiple background services could interleave/corrupt log lines, and a dispose racing a write could throw ObjectDisposedException.

Changes

• src/ArmRipper.Core/Infrastructure/JobLogger.cs
  • Serialize file writes with lock (_writeLock) in Log<TState>.
  • Acquire the same lock in Dispose/DisposeAsync before flushing/closing.
  • Add a _disposed guard so late writes after dispose are no-ops instead of throwing.
  • DisposeAsync now delegates to the locked Dispose (avoids holding a Monitor across awaits).
• tests/ArmRipper.Core.Tests/JobLoggerTests.cs (new)
  • ConcurrentLogs_AllLinesPreserved — 200 parallel writes; asserts every line is intact and no interleaving/corruption.
  • Log_AfterDispose_DoesNotThrow.
• docs/code-review/README.md + 02-joblogger-thread-safety.md — mark refactor: add consistent DiagnosticSource categories for all logging … #2 as Done (Todo 25 / Done 11).

Verification

• dotnet build — 0 warnings, 0 errors.
• New JobLogger tests pass (2/2).
• Full test run: the only failures (MakeMkv/Omdb/Conductor/WebUi integration) are pre-existing on master — confirmed by running the identical suite on a clean master worktree (identical failure sets, zero new failures).

Notes

JobLogger is currently unused by production code (the pipeline routes through the already-thread-safe JobFileLoggerProvider), but the review item explicitly required hardening it, so it is now safe to use.