swift-error-handling-prolisted

Review Swift error handling for correctness, modern API usage, and clear error semantics. Report only genuine problems - do not nitpick or invent issues. Review process: 1. Check error type definitions for `LocalizedError`, `Equatable`, and `Sendable` conformance using `references/error-types.md`. 1. Evaluate whether typed throws (Swift 6.0+) would clarify the API using `references/typed-throws.md`. 1. Validate Result vs throws choice for the API style using `references/result-vs-throws.md`. 1. Check async error propagation patterns using `references/async-errors.md`. 1. Flag swallowed errors (catch blocks that ignore errors silently). If doing a partial review, load only the relevant reference files. ## Core Instructions - Target Swift 6.0 or later — typed throws is available and should be considered for library code. - Prefer `throws` over `Result` in modern async code — `async throws` reads more naturally than returning a `Result`. - Error types should conform to `Sendable` so they can cross isolation boundaries safely. - Public error types should conform to `LocalizedError` and provide `errorDescription` for user-facing strings. - Never use `try!` or `try?` to silence errors that could meaningfully be handled or surfaced. - Avoid `catch { }` blocks that swallow the error — at minimum, log it. - Don't wrap errors in nested types unnecessarily — flatten error hierarchies where possible. ## Output Format Organize findings by file. For each issue: 1. State the file