Proposal: make the breadcrumb ancestor budget configurable in query results and references

Nobody has claimed this yet.

Opening this per [CONTRIBUTING.md](https://github.com/logseq/logseq/blob/master/CONTRIBUTING.md#submit-pr) ("If you would like to *implement* a new feature, please open an issue and outline your proposal so that it can be discussed"). I have a working implementation and would like to contribute it, but I would rather agree on the shape first.

## Context

In the DB version, breadcrumbs in List View query results and in Linked/Unlinked References keep the first ancestor and the direct parent, and fold everything between them into the `Show more ancestors` dropdown. That is deliberate — it came in with logseq/logseq#12595, which explicitly "collapse[s] middle ancestors behind an overflow indicator while preserving page context and nearest parent context". With the `:inline` budget of `:max-visible 3 :nearest-count 1`, folding starts at about four levels below the page.

**I am not proposing to change that default.** I would like an opt-in way to turn it off.

## Why it matters for some of us

The value of a breadcrumb in a result list is scanning: glancing down the results and seeing at once where each block lives. The dropdown is good at answering "where is *this* block", but it cannot answer "how do these results differ", because it costs a click per row, covers the results while open, and closes again, so two paths can never be compared. For deeply nested blocks the two segments that stay visible are often the least discriminating part of the path — the distinguishing context is exactly the middle that gets folded.

This is the one thing keeping me (and, judging by the forum, others) on the file version for a set of workflows built around deep hierarchies, where the file version showed the full path inline.

## Proposal

A user setting controlling the ancestor budget for the `:inline` variant only — query results and linked/unlinked references. Header and Cmd-K breadcrumbs stay as they are; they are space-constrained by design.

```clojure
:ui/breadcrumb-max-visible :all ;; never fold
:ui/breadcrumb-max-visible 6 ;; or keep 6 segments and fold the rest
```

Absent or invalid, behaviour is byte-identical to today.

## Implementation status

I have this working against current `master`, as a small patch:

- `variant-options` in `frontend.components.block.breadcrumb-model` gains a pure `user-overrides` helper that turns the config value into display-budget overrides.
- The single `variant-options` call site in `frontend.components.block/breadcrumb-aux` merges them in, which covers the overflow dropdown too since it inherits the same options.
- The default `config.edn` template documents the key, commented out.
- Unit tests for the new helper and its effect on `build-breadcrumb-view`.

No query, worker or schema changes: the breadcrumb payload already carries the ancestor chain, so only the display budget is involved.

Three things I would flag about it:

1. `:nearest-count` has to be raised alongside `:max-visible`, otherwise an integer value acts only as a *folding threshold* — `6` would render identically to `3`, since the visible count when folding occurs comes from `:nearest-count`. I made the configured number the count actually displayed, but that is a judgement call.
2. With `:all`, paths deeper than 16 levels still start mid-chain, because `block-breadcrumb` loads at most 16 ancestors. Raising that would inflate every block payload, so I left it alone.
3. Scoped to `:inline` deliberately, as above.

## Question before I open the PR

Would you prefer this as a `config.edn` key, or as a toggle in Settings? The DB version seems to be moving settings into the UI, and I would rather build whichever one you would accept. I am happy to sign the CLA and open the PR against `master`.

Start with variant-options in frontend.components.block.breadcrumb-model and the call site in frontend.components.block/breadcrumb-aux; review how the inline display budget reaches build-breadcrumb-view. Check the mentioned unit tests and config.edn template. Done means an accepted configuration shape changes inline query and reference breadcrumbs while preserving current defaults and leaving other variants unchanged.

Written by the indexing model from the issue text.