wire up ProgressIndicatorSpinner where borg goes silent for a long time

Follow-up to #10081, which added `ProgressIndicatorSpinner` but no caller for it yet.

Since the spinner repaints in place and is FPS rate limited, it can be called from inside a hot loop, so it fits the spots where borg currently goes quiet for a long time and looks hung. Candidate call sites, checked against master (91129b2a6):

1. Chunk index fragment merge in `build_chunkindex_from_repo()` (`src/borg/cache.py`): the `for hash in hashes:` loop loads and merges one fragment per iteration and logs only at debug level, so at info level nothing is output while it runs.

2. Slow chunk index rebuild, same function: `for info in repository.store_list("packs")` issues one range request per pack through `PackReader.iter_headers()`, and the only output is a single debug line after the whole loop.

3. Lock acquisition in `Lock.acquire()` (`src/borg/storelocking.py`): the retry sleep loop also only logs at debug level, so with a long `BORG_LOCK_WAIT` borg sits silent while waiting for another client to release the lock.

4. The `store.list()` materializations, `Repository.store_list()` and the local `store_list()` in `Repository.check()`. Both do `list(self.store.list(ns))`, one blocking call with a repo-sized latency. Using the spinner here means consuming the generator in a loop instead of materializing it first, so it is a slightly bigger change than the others.

Not in scope:

- `Cache.close()`: single-call phases, nothing would animate there.
- `borg create`: `process_file_chunks()` already calls `stats.show_progress()` per chunk, so the display keeps moving inside a large file.

One thing to settle before I start: `_setup_implied_logging()` in `src/borg/archiver/__init__.py` puts `borg.output.progress` at WARN unless `--progress` was given, so the spinner stays silent without it. Should these life signs stay behind `--progress`, or should the spinner animate by default? That decides whether 3 is worth doing at all, since a user waiting on a lock has usually not passed `--progress`.

I would do one PR per area rather than one big one. Happy to reorder the list or drop items from it.

Read #10081 and the existing ProgressIndicatorSpinner, then inspect build_chunkindex_from_repo() in src/borg/cache.py, Lock.acquire() in src/borg/storelocking.py, and the store_list() call sites described in the issue. Resolve whether spinner output remains behind --progress before choosing an area. Done means the selected long-running quiet loop visibly reports progress without changing the explicitly out-of-scope areas.

Written by the indexing model from the issue text.