SIGN IN SIGN UP

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