Error-formatting helper

## Summary

This may be a nice-to-have, but it would make `fhir-zod` easier to use in real applications and agent-driven workflows.

Today consumers get raw Zod validation errors, which are correct but not always the most ergonomic shape for logs, UI, API responses, or automated repair loops. A small helper layer could make common validation failures easier to understand and easier to act on without changing the generated schema surface.

## Problem

`safeParse` and `parse` already give access to Zod's error data, but most consumers do not want to hand-roll the same formatting logic repeatedly.

Common needs:

- produce concise human-readable messages
- preserve machine-readable field locations
- group or flatten repeated issues
- optionally map validation failures into a FHIR-friendly shape
- make validation failures easier for coding agents to repair automatically

## Possible direction

Add a small helper API at the root package level, for example:

- `formatFhirError(error)`
- `flattenFhirError(error)`
- `toOperationOutcome(error, options)`

This does not need to be part of the core schema generator story. It could stay as a thin convenience layer over Zod errors.

## Prior art to review

- Zod already exposes error-formatting helpers such as tree/flatten formatting: https://zod.dev/ERROR_HANDLING?id=formatting-errors
- HL7 FHIR `OperationOutcome` is the standard error container for computable issue reporting, including issue severity, code, diagnostics, and `expression` paths: https://www.hl7.org/fhir/operationoutcome.html
- FHIR servers and validators commonly return structured `OperationOutcome` responses for validation failures; that shape may be a useful target even if `fhir-zod` keeps the helper optional.

## Open questions

- Should this stay generic and Zod-shaped, or should it lean into FHIR `OperationOutcome`?
- Should it emit FHIRPath-like `expression` values when possible?
- Should helpers live only at the package root, or also be exposed per version?
- How much normalization should happen versus leaving raw `ZodError` details intact?
- Do we want one canonical formatting helper, or a few small helpers for different output targets?

## Why this seems worthwhile

The library is already strong on validation correctness. A small formatting helper would improve the last mile for:

- API/server responses
- CLI/debugging output
- test snapshots
- UI form error presentation
- agent loops that need structured feedback to repair payloads

It also gives us a place to document recommended error-handling patterns instead of expecting every consumer to invent their own.