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

[vibl]

Opening this per CONTRIBUTING.md ("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.

: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.