Constant MAX_RESOLVABILITY_CANDIDATES 

pub const MAX_RESOLVABILITY_CANDIDATES: usize = 16;

Count image markers in the latest user message whose references would actually resolve to an attachment: an inline data: URI that passes the shared structural check, a remote http(s) URL when remote_allowed is set (counted without any network access), or a local path that the caller’s path_allowed predicate accepts and that exists as a file. Marker syntax alone does not count, so prose that merely looks like a marker cannot fail a turn on a text-only model.

A local reference counts only when it is absolute AND path_allowed accepts it. Relative references never count: this module has no agent workspace of its own, and a bare existence check would resolve a relative reference against the process working directory instead, which is not where the runtime’s file tools resolve relative paths, so there is no answer this module could give that matches the loader. The predicate exists because the ledger of who may read a path is the agent’s filesystem policy in the runtime, which this crate cannot depend on; callers pass the same check their file tools apply, so “resolvable” means exactly “the agent could read this file”.

This touches at most the markers of the latest user message. The classification pass over them is inline and I/O-free: a data: reference needs only the shared structural check, a remote URL only the remote_allowed flag, a relative reference never counts, and an absolute reference only appends to a candidate list. For at most MAX_RESOLVABILITY_CANDIDATES absolute candidates the caller’s path_allowed predicate and one std::fs::metadata existence probe each run inside a single tokio::task::spawn_blocking task, so no policy-resolution or filesystem work runs on the async executor thread (a predicate may do arbitrary synchronous filesystem work; the runtime’s resolves symlinks). A path the predicate rejects is never probed, and neither is a relative reference, a data URI, or a remote URL. It does no network I/O and no decoding.

The maximum number of absolute local-path markers in the latest user message for which ANY work runs, policy resolution and the existence probe alike: at most this many candidates reach the one [tokio::task::spawn_blocking] task inside count_latest_user_resolvable_image_markers. Absolute markers past the bound count as resolvable with NO policy call and NO probe, so the caller fails toward its loud capability error, never toward silently degrading away a real attachment (over budget the count can only grow). The bound sits BEFORE the policy check, so a message cannot buy unbounded policy work with unbounded markers; this is a semantic change from the earlier probe-budget shape, which still ran the policy for overflow markers. The bound exists because no upstream limit bounds the marker count of a single inbound user message (transport frame caps operate at megabytes, not markers). parse_image_markers remains the single source of truth for what a marker reference is, and split_base64_image_data_uri for what a valid inline data URI is.