Decide whether KNOWN_ISSUER gates received-token issuers on inflow legs

[christian-rogobete]

The value descriptor records inflow legs (Blend withdraw/borrow proceeds, vault withdrawals) so every leg of a call is visible, but the counterparty KNOWN_ISSUER check scopes to debit legs only: receiving a token via a DeFi withdrawal is not gated against the issuer allowlist. This matches the pre-descriptor behavior (DeFi counterparty was never checked) and receiving tokens cannot drain funds, so the skip is deliberate — recorded here so it is a decision rather than an accident. If inflow gating is wanted (reject receipt of untrusted-issuer tokens), it is an additive expansion of the KNOWN_ISSUER semantics over non-debit legs. Assess after the descriptor migration completes.

[christian-rogobete]

Security-review guidance recorded during the descriptor step-3 review, for whoever picks this up:

1. Do NOT fold inflow gating into counterparty_allowlist. An inflow leg has no outbound counterparty — its effective destination is the wallet itself — so gating it against a counterparty allowlist is a category error.
2. A naive inflow-issuer gate would be actively harmful: a Blend or vault withdrawal returns the same asset previously supplied, so denying its return strands funds. Any inflow gate must exempt the return leg of a previously permitted supply, which requires state the counterparty criterion does not have.
3. The residual threat (dust/spam tokens, malicious SAC honeypots) is an asset-acceptance / trustline-hygiene class, partly bounded already: classic assets cannot be received without an explicit trustline, which is itself a gated tool; only SAC receipt is the open surface, and holding is not loss — any actual loss happens on a later outflow the caps and counterparty checks already gate.

If built, this is a separate, explicitly named received-asset-issuer criterion on the asset-acceptance axis.