BREAKING CHANGE: legacy passkey flagging no longer runs automatically on engine
start. It is now revision 0001 of the package's migration manifest and requires
WithMigrations from @algorandfoundation/provider-migrations to be installed on
the provider. Applications that do not add it will never flag legacy passkeys.

Code review flagged that the migration-registration test never exercised the
real createReactNativeKeyStore path, so nothing asserted that the migration's
context() returns the very same storage object the engine reads/writes. Adds
a test that constructs the real engine and checks reference identity;
verified it fails when the invariant is broken.

Step [5] is the reviewer's "byte-exact reconstruction of the message M a
live inscription must have signed". It read the wrong bytes.

InscriptionRecord is an arc4.Struct, so the ARC4 head packs fixed-size
fields in declaration order:

  version         UInt8                  rec[0:1]
  cell_id         UInt64                 rec[1:9]
  artifact_hash   StaticArray[Byte,32]   rec[9:41]   <- the signed bytes
  inscribed_round UInt64                 rec[41:49]
  inscriber       Address                rec[49:81]
  payload_uri     DynamicBytes           rec[81:83] -> tail

The code used rec[0:32], which is version || cell_id || the first 23 bytes
of the hash. Confirmed against live TestNet cell 763809098: rec[0] == 1 and
rec[1:9] == 763809098, matching the box name exactly, so the layout is not
in doubt. The script displayed

  rec[0:32] = 01000000002d86cd4a5680fc4ddf9d331b585198239ab41bdc768e3192efc477
  rec[9:41] = 5680fc4ddf9d331b585198239ab41bdc768e3192efc477793a9daa1445dd4574

and rebuilt M from the first. No signature has ever covered those bytes.

It went unnoticed because the sole assertion was len(M_live) == 102, and
build_message validates both inputs are 32 bytes and then concatenates
fixed-width fields - so it either raises or returns exactly 102. The check
could not observe a wrong hash. Same shape as the approval-program pin
this branch already replaced: an assertion with no reachable failure.

Replaced with checks that can fail:
  - version == 1
  - the cell_id INSIDE the record equals the cell_id in the box NAME. Two
    independent sources for one claim, and the check that actually pins the
    offsets above. Mutation-tested: reading rec[0:8] instead of rec[1:9]
    yields "record 72057594040911565 vs box 763809098" and fails.
  - M matches the spec layout at every field offset, so a drift in
    build_message surfaces instead of being absorbed.

Note the tempting check is NOT sufficient: comparing M's embedded hash to
art32 would have passed under the old bug too, since both sides shift
together. That is why the layout is pinned by the cross-source comparison.

Also states plainly that M is reconstructed, not verified: the signature is
a call argument the AVM checks, and is not stored on-chain, so no local
signature verification is possible from box state alone.

Live: 17 passed, 1 failed (the failure is the deployment drift). Standalone,
without the committed artifact: 17 passed, 0 failed.

Found by an adversarial claim-vs-enforcement sweep (TCE-02).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>