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>

Adding the previous step revealed why the Windows leg was skipping: the
DLL built, linked and loaded with an EMPTY export table.

MSVC exports nothing from a DLL without __declspec(dllexport) or an
explicit /EXPORT, whereas ELF and Mach-O export every non-static symbol.
The upstream Falcon sources carry no dllexport annotations. Evidence from
the failing run: the linker never printed "Creating library", which MSVC
emits only when at least one symbol is exported.

So on Windows every ctypes lookup raised, _lib_available() caught it under
a bare `except Exception`, and the tests skipped with the reason
"FALCON_DET1024_LIB not built/set" - which was FALSE. The log shows the
variable set correctly to a real file that exists. The diagnostic named
the one thing that was not wrong.

Consequence: the Windows leg of the 3-OS byte-identity matrix has verified
nothing since it was written, while reporting green. The cross-platform
reproducibility claim it exists to support (reviewer Q11/Q7, and the
"byte-identical on Linux, macOS and Windows" language in the KAT header)
held on two platforms of the three it names.

S2.6 forbids editing the audited reference, so the exports are declared at
link time rather than by annotating the C sources. The four names are
exactly the SDK's audited binding surface, which makes the Windows export
table an enforcement of that allowlist: a binding added without a matching
export now fails loudly here.

Not reproducible locally - no MSVC on this machine - so CI is the
verification. The preceding step's grep is what will confirm it: if the
exports work, no test can report "FALCON_DET1024_LIB not" and the job
goes green having actually run the cryptography on Windows.

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

Thirteen tests behind skipif(not _lib_available()) had never executed in
CI, on any event, since the workflow was written. The two jobs each had
half of what was needed and neither had both:

  wire-format    runs `pytest tests` (the whole suite) but never builds
                 the Falcon C library, so every lib-gated test skipped.
  signature-kat  builds the library on 3 OSes but ran only
                 `pytest tests/test_signature_kat.py`.
  testnet-e2e    builds the library, runs no pytest, and is manual-gated.

The intersection was empty. The never-run set is not incidental - it is
where the constitution's hardest crypto rules are actually enforced:

  test_seal_wipes_private_key_buffer             S2.3 zeroization
  test_worker_stdout_carries_only_public_values  S2.3 no secrets in output
  test_isolated_result_has_no_private_key
  test_isolated_require_locked_fails_closed_when_mlockall_unavailable
  test_bad_build_fails_closed_without_consuming_cell
  test_seal_signature_verifies_and_has_0xBA_header
  test_second_seal_of_same_cell_raises
  test_isolated_seal_produces_verifying_signature
  test_isolated_second_seal_raises
  + 3 signature fuzzers and 1 interop cross-verify

Every green CI run has reported success while the private-key
zeroization check and the secret-leak-to-stdout check did not run.

This adds one step to signature-kat, the only job that builds the
library, running the full suite there.

The grep is not belt-and-braces, it is the substance: without it a failed
library build silently returns all thirteen tests to "skipped" and the job
goes green again, reintroducing this exact defect in the exact place it
was removed from. Passing must require that they RAN, not merely that
nothing failed. Same reasoning as TRELYAN_REQUIRE_KAT one step above,
which was applied to the KAT and never extended to its neighbours.

set -o pipefail so the tee does not swallow pytest's exit code.

Found by an adversarial sweep for claims that nothing mechanically
enforces; this was the highest-severity survivor.

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

The pinned build (ce15e75b = tag v0.1.0, the release go-algorand vendors)
has a confirmed size_t underflow in falcon_det1024_convert_compressed_to_ct
giving an unbounded read. TRELYAN's documented position is accept-and-
document, and it rests on exactly one fact: the SDK never binds that
function. The pin is deliberately NOT bumped - ce15e75b is the network's
release, and the untagged fix commit would make TRELYAN stricter than the
deployed on-chain verifier for no reachable benefit.

That makes the acceptance only as durable as the binding surface, and
nothing was watching it. A later commit adding CT-format support would
convert a documented non-issue into a live out-of-bounds read silently.

sdk/tests/test_binding_surface.py derives the bound symbol set by parsing
the AST of _bind() and compares it to a declared allowlist. Note this is
NOT the tautology it resembles: the two sides come from independent sources
- one parsed from the source, one the security policy - so it can fail. A
constant compared against itself cannot. The correct response to a failure
is to justify the binding, not to edit the allowlist green.

A second test sweeps all shipped sources textually, catching dynamic access
(getattr(lib, ...)) that the AST check on _bind() alone would miss. A third
asserts the extraction itself works, so the guard cannot pass vacuously.

Static only - no shared library is loaded, so it runs in the no-native-lib
CI job.

Verified by mutation, not just by passing: injecting
lib.falcon_det1024_convert_compressed_to_ct into _bind() turns both guards
red with the quarantine reason attached; reverting turns them green. Full
SDK suite 24 passed / 18 skipped (skips are the native-lib tests).

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