Biome fix pass scope—safe versus unsafe edits in automation

Goal

Establish a consistent policy for running Biome's in-place fix pass (`biome check --write`) in CI and pre-commit hooks, deciding whether to include unsafe fixes that may change runtime behavior.

Constraints and uncertainty

Biome edits files directly and provides no backup or snapshot mechanism; version control is the only rollback. The flag surface for applying fixes has shifted across major releases—some versions use `--write`, others `--apply`, and unsafe fixes may be gated behind `--unsafe` or `--apply-unsafe`. Safe fixes are intended to preserve semantics but can still produce broad diffs, reorder imports, or reformat code. Unsafe fixes explicitly opt into behavioral changes. Running `--write` on a dirty working tree mixes automated edits with unrelated changes, complicating review.

Questions

1. Should automation run only safe fixes (`biome check --write`) or also include unsafe fixes (`--unsafe` or equivalent) after tests pass?
2. How should the policy handle flag differences across Biome versions used in the project?
3. What verification steps (diff inspection, test suite, JSON reporter comparison) are required before merging automated edits?