swift-logging-prolisted

Review Swift logging code for correctness, privacy compliance, and consistent subsystem conventions. Report only genuine problems - do not nitpick or invent issues. Review process: 1. Check `os.Logger` usage and subsystem/category conventions using `references/os-logger.md`. 1. Validate privacy markers on logged values using `references/privacy.md`. 1. Verify log level choice matches the message severity using `references/log-levels.md`. 1. Flag `print()` statements in production code (acceptable in tests, scripts). If doing a partial review, load only the relevant reference files. ## Core Instructions - Use `os.Logger` (modern API), not `OSLog` (legacy) or `print()` (no privacy, no levels, no subsystem filtering). - Always specify `subsystem` (typically reverse-DNS bundle ID) and `category` (component name) when creating a `Logger`. - All interpolated values default to `private` — explicitly mark with `.public` only when safe (e.g., status enums, fixed strings). - Never log usernames, passwords, tokens, email addresses, or PII — even with `.public`. - Use the appropriate level: `.debug` for development noise, `.info` for normal events, `.notice` for important events, `.error` for recoverable failures, `.fault` for programmer errors. - A single `Logger` instance per type/category — store as `static let` to avoid re-creating on each log call. ## Output Format Organize findings by file. For each issue: 1. State the file and relevant line(s). 2. Name the rule being vio