borg check should take "notes"

Many borg users will use regularly scheduled `borg create` and `borg check` jobs to create and verify their backups.

If there is a lot of data in the repo, `borg check` will take a long time, but that should not be a problem because it runs unattended and also its runtime can be limited.

BUT, if there are issues with a repository (e.g. the check job detecting something), usually the repo admin will try to fix issues interactively and interactive operations should be fast.

That means:
- we should not need to run a full `borg check` again (processing all packs / all objects in the repo)
- `borg check [--repair]` should re-use intelligence that previous `borg check` runs have gathered (e.g. IDs of corrupt packs, IDs of corrupt or missing objects)
- `borg create` could have a special treatment (re-chunk them!) for paths of files that were noted as corrupted or containing missing chunks by `borg check`.

Start by tracing the `borg check` and `borg create` command entry points and how they currently process repository packs, objects, and file paths. The issue is done when a defined notes mechanism lets later check or repair operations reuse prior findings and allows create to re-chunk affected paths, with behavior and scope agreed first.

Written by the indexing model from the issue text.