Report a missing map key distinctly from a failed lookup
Reading a value by key out of a merkleized map has two outcomes that callers must tell apart: the key is genuinely not in the map (normal for every optional PSBT field), or the lookup failed (Merkle proof mismatch, malformed client response, transport error). Previously, the API collapsed both into a single negative return, so a caller applying a default for an optional field would also apply it after a proof failure, swallowing what should logically be an error. The shared contract lives in the new map_value_status.h, which also documents that MAP_VALUE_ABSENT is a client assertion and not a proof: the device requests no proof of absence, so a suppressed key is indistinguishable from an honest omission. Where soundness is required, presence must be derived from the key enumeration performed while validating the map, which is committed to by keys_root. No caller behaviour changes here: every current caller tests `< 0`, which stays correct. Three tests that pinned the old granular codes now assert the named ones, and the not-found test is strengthened from `< 0` to MERKLE_LEAF_NOT_FOUND.
S
Salvatore Ingala committed
941235f8abf3b6ce623a57ae89430285a574469f
Parent: 5231c79