Preserve Biber comments within entries

[claell]

Summary

• Parse Biber-style percent-comment lines inside entries before field parsing can absorb them as data.
• Represent nested comments separately from active bibliography fields, with their source field-boundary positions.
• Preserve those comments during canonical writes, including after callers remove fields.
• Cover field-shaped comments, punctuation, CRLF input, top-level-comment compatibility, copying, and model invariants.

Closes #372.

Default behavior

This is implemented in the structural parser rather than as opt-in middleware. A middleware cannot recover a comment that has already caused field parsing to fail or absorb subsequent syntax. The parser therefore recognizes a line whose first non-whitespace character is % inside an entry and retains it in Entry.comments; it does not expose the text as an active field.

The canonical writer preserves content and relative field boundaries, not byte-identical whitespace. Callers may inspect or edit the explicit EntryComment objects. No dialect flag is required merely to avoid losing Biber input.

Validation

• Focused Biber-comment and affected model tests under warnings-as-errors: 50 passed.
• Complete upstream suite: 2,584 passed, 12 skipped, with the four existing deprecation warnings in tests/test_entrypoint.py.
• Complete pre-commit hook suite: passed.

Review note

This adds public model state to Entry and changes splitter marks, so careful API and parser review is requested. The branch includes the same small _skip_marks_before iterator helper independently needed by PR #571; whichever PR merges second should remove the duplicate during rebase.

AI assistance

This pull request was prepared with ChatGPT Codex using GPT-5.6 Sol with high reasoning effort. Codex assisted with architecture analysis, dependency removal, edge-case testing, and validation. Automated validation is not a substitute for maintainer review.

[MiWeiss]

Hi @claell — same note across all of your July 16 issues and PRs (#567–#597), apologies for the repetition.

Closing this. Passing CI isn't evidence the underlying claim is real — it just means generated tests match generated code. The batch's timing, structure, and forward-referenced numbers point to this being AI-generated rather than manually found and checked, and reviewing it properly would take more effort than a targeted pass over the parser myself.

If this fixes something you actually hit: open a small, human-verified PR against a reopened issue with a real repro, and I'll review it in good faith. Any nontrivial design or API choice needs to be discussed and agreed first, not decided inside a PR. Please disclose and verify AI-assisted work before submitting going forward.