build(deps-dev): update @typescript-eslint/eslint-plugin requirement from ^8.66.0 to ^8.67.0

build(deps-dev): update @typescript-eslint/parser requirement from ^8.66.0 to ^8.67.0

Documentation only. Neither changes behaviour, and the contract's bytecode is
verified unchanged: 667 B, sha256 308cfa75, identical before and after the
comment edit (recompiled with puyapy 5.8.1 at AVM 12, assembled via algod).

1. BOX MIN-BALANCE understated. inscription.py stated "~0.72 ALGO/cell
   (~737 ALGO across all 1024 cells)". That is a rounded per-cell figure
   multiplied up -- 0.72 x 1024 = 737.28 -- and it counted only ONE of the
   three boxes a cell uses.

   Algorand charges 2500 + 400*(name+value) microAlgos per box; a BoxMap name
   here is a 2-byte prefix plus a uint64 key = 10 bytes:

     committed_pubkey   10 + 1793  -> 723,700 uA = 0.7237 ALGO  (x1024 = 741.1)
     controlling_owner  10 +   32  ->  19,300 uA = 0.0193 ALGO
     inscriptions       10 + ~83.. -> ~40,500-66,100 uA         (payload_uri varies)

   Per fully-inscribed cell ~0.78-0.81 ALGO; across 1024 cells ~802-829 ALGO,
   not 737. Even read narrowly as the committed-key box alone it is 741.1, so
   the figure was low either way. deploy_testnet.py's own "~0.9 ALGO"
   per-deployment estimate was already correct -- it is the fully-minted total
   that was wrong, and it is described as an accepted Foundation cost.

2. FALCON_BUDGET_2026-06-01.md bills opcodes for a step that does not execute.
   The table charges sha512_256(pubkey) (C5) at ~45-200, and a "Contract update
   (1 Jun)" note says inscribe "now runs C5 before C4".

   inscription.py L71-73 says that step "is removed -- it was a storage
   optimization, not a security property". The key lives in box state and
   inscribe READS it; there is no pubkey argument and no sha512_256 call in the
   contract at all.

   Consequences stated precisely: the real total is ~1,750-1,800, LOWER than
   the ~1,850-2,050 quoted -- the memo overstated, which is the safe direction,
   but it is still a number an auditor re-derives. And the A5 claim, "a
   wrong-key attempt is rejected for ~45-200 instead of the full 1700", no
   longer applies: there is no supplied key to pre-check. Narrow exposure,
   since the caller funds its own OpUp budget, but a mitigation the code does
   not implement should not sit on the books.

   The OpUp recommendation is unaffected: 3 app calls (2,100) is required at
   1,750, 1,800 and 2,050 alike -- checked, not assumed.

build_message used `int(app_id).to_bytes(8, "big")`. That coerces rather than
validates, and the coercion is lossy. Measured before the fix:

    float 1001.9  -> encoded as 1001    <- SILENT TRUNCATION, in a signed message
    str  "1001"   -> encoded as 1001
    bool True     -> encoded as 1

Meanwhile `cell_id`, encoded two fields along in the same function, was
strictly range-checked the whole time. One field validated, the adjacent one
coerced.

Worse, the contracts-side copy called `app_id.to_bytes()` directly, so it
RAISED on a float or a str. Two implementations of one signed message format
disagreed about whether an input was even legal -- in the pair whose entire
reason for existing separately is that they must agree byte-for-byte.

Both now apply the same guard. bool is excluded explicitly: isinstance(True,
int) is True in Python, so a bare isinstance check would encode True as
app_id 1, which is a real application ID.

Fail-closed either way -- a wrong app_id yields a signature the chain rejects,
not an accepted forgery. But a signing path that silently truncates its input
is not something to leave standing in a repo heading for audit.

11 new tests on top of the existing differential file, including one asserting
the two implementations REJECT identically, not merely accept identically --
agreement about what is illegal is half of what "these must match" means.

Mutation-proved: restoring `int(app_id)` fails 12 tests. SDK suite 63 passed,
19 skipped.

Three defects in the branch that exists to prove the committed artifact is not
trusted. It has never once run to completion.

1. NO --target-avm-version. The contract calls op.falcon_verify, an AVM 12
   opcode; puyapy's default target is lower, so compilation FAILS outright:

     assert op.falcon_verify(m, falcon_sig.native, pubkey), ...
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   contracts/requirements.txt documented the correct invocation the whole time
   ("--target-avm-version 12"). The flag is now DERIVED from the committed
   artifact's own `#pragma version` line rather than hard-coded, because a
   literal could drift from the artifact it is meant to reproduce.

2. THE FAILURE HAD NO REASON. puyapy writes diagnostics to STDOUT; the handler
   read only exc.stderr. Measured on a failing compile: stderr 0 bytes, stdout
   848. So an operator hitting (1) saw literally "puya failed:" and nothing
   else. Now prefers stdout, falls back to stderr, and says which exit code.

3. IT OVERWROTE THE ARTIFACTS IT WAS VERIFYING. recompile_from_source was
   passed args.teal.parent -- contracts/out/ -- so running the verifier
   rewrote five tracked files as a side effect: both .teal, both .puya.map and
   the .arc56.json. A verifier that mutates its subject cannot be run on a
   clean tree, and its second run compares the output against itself. Now
   compiles into a TemporaryDirectory.

4. IT COMPARED TEAL TEXT, NOT BYTECODE, and would have reported "stale" on a
   contract that is perfectly reproducible. Measured against puyapy 5.8.1 /
   algorand-python 3.5.0 at AVM 12: committed TEAL 17,559 bytes, fresh compile
   18,179 -- 620 apart, and NOT a line-ending artifact (LF-normalising both
   does not close it). Yet both assemble to the same 667-byte program,
   sha256 308cfa75. The difference is comment and source-map formatting from a
   different compiler build.

   Bytecode is what deploys and what the drift check further down compares, so
   it is the only comparison that answers the question. Text comparison made
   the check fail on compiler-version noise while claiming source and artifact
   disagreed -- a false alarm in the one tool whose credibility depends on its
   alarms being real.

Verified end to end, first time this branch has completed:

  [0] ok    committed TEAL assembles identically to a fresh compile
  [2] expected bytecode 667 B  112fcad3...
  [3] actual   bytecode 660 B  d24d9071...
  DRIFT - application 763809096 is NOT running the committed source.

...and `git status contracts/out/` is clean afterwards.

The drift at [3] is the real, already-filed finding (TCE-01/TCE-35). What
changed is that [0] now runs and is trustworthy.