feat(assets): the user's broker holdings as a candidate source

[eaitbrahim]

Adds the missing source for allowlist candidates: the assets you actually hold at the broker.

keel assets holdings [--min-balance N] [--screen]

It answers "what do I already own that this system might trade?", where keel assets discover answers "what could anyone trade?".

A source, not a gate

Holding an asset is not a reason to trade it. This command admits nothing and writes nothing — no attestation, no allowlist change, no DB write. It is a read-only report, in the same family as assets discover.

The vetting itself is unchanged. screen_asset and its policy are untouched: if this work had needed to weaken the gate to let the user's own holdings through, that would have been evidence against the holdings, not against the gate. An unattested asset you hold is still REJECT — sector and backing cannot be derived from a balance any more than from a price.

2 holding(s) above 0, excluding USDC and fiat:

  BTC      balance=0.5      on-allowlist     UNATTESTED
      REJECT  (2000 daily bars cached)
      x attestation: MISSING. ...
  SOL      balance=12       not-on-allowlist UNATTESTED
      REJECT  (0 daily bars cached)
      ! no local history -- run `keel fetch --products SOL-USD` first, then re-screen.
        This is a MISSING-DATA verdict, not a verdict about the asset.

One gate, shared by construction

assets screen inlined the attestation lookup and the screen_asset call. That is extracted to _screen_product, and both commands now route through it — so a proposer cannot drift onto a laxer path. A test asserts the two commands reach the same verdict for the same asset.

This is also the seam the future LLM proposer must use. Recorded in the spec: per the project's asymmetry principle an LLM may propose and may veto, but may never admit. Admission still requires a human keel assets attest with a source, a passing screen, and a deliberate config.allowlist edit. Nothing here grants a proposer new authority.

Two things found while building it

• Screening {asset}-{quote_currency} would have made the feature useless. Daily history is keyed -USD throughout this codebase (_default_sim_products, keel fetch, keel simulate), while quote_currency is USDC. Screening the settlement product would have found zero cached bars for every asset and reported "no local history" forever — which is worse than useless, because it reads as a verdict about the asset. The convention is now single-sourced in _history_product, and my own test caught this by asserting the two commands agree.
• "No local history" is not "bad asset". The likeliest misreading of the whole feature, so it is handled in the output rather than left to the operator, and it names the keel fetch that fixes it.

Verification

1300 tests pass, ruff clean. Nine new tests: fiat/settlement-currency exclusion, dust filtering, held-but-unattested is still rejected, both commands agree on one asset, the missing-data message, the command writes nothing (asserted, not assumed), and a broker failure is an error rather than an empty result that would falsely read as "you hold nothing".

Design: docs/superpowers/specs/2026-07-21-holdings-as-candidate-source-design.md.