Public nodes can disable API auth. Always setting X-Algo-API-Token to an
empty string caused those requests to fail. Only send the header when
both the header name and token are non-empty.

Fixes #653.

Closes algorandfoundation/algorand-typescript-testing#145

Ships the tested upgrade script so clusters carried through pg_upgrade at
0.2 can reach 1.0 with ALTER EXTENSION pg_algorand UPDATE, without the
drop/recreate dance. CREATE OR REPLACE upgrades the two functions with
dependents in place; the three GetNFD* functions are dropped and
recreated because 1.0 renamed their parameters. Verified on betanet,
testnet x2 and mainnet upgrades (identical to a fresh 1.0 install).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ACfCvu2UPpd6UcoK8cpW3

- Introduced Falcon-1024 account type with corresponding UI elements and localization in Russian, Slovak, and Turkish.
- Implemented account creation, import, and export functionalities for Falcon accounts.
- Added Falcon-specific mnemonic generation and validation.
- Integrated Falcon signing mechanism for transactions.
- Updated routing to include Falcon account creation page.
- Enhanced backup warnings and account management features for Falcon accounts.
- Added unit tests for Falcon account functionalities.

fix: reject negative extra_pages in appcall transactions

It asserted that escrow entries outnumber self entries in beneficiaries.json,
which held while the cache only ever saw fxALGO holders — those sit almost
entirely in Folks escrows (~3333 of ~3352 per the README).

56d8577 broadened the candidate set to both assets, and plain xALGO holders
are wallets, so they resolve to self. The cache is now 3978 escrow / 8046 self
(33%), and the premise is false by design rather than by regression. The file
does not record which asset a candidate came from, so the fxALGO-only ratio
cannot be recovered from it.

The two remaining assertions still cover the file's real invariants: ordering
and address validity, and that every escrow entry names a tracked app, a valid
owner distinct from the escrow, and an opt-in round.

Stage 3 ran one source at a time, so three multi-minute Indexer window
scans summed instead of overlapping. Splitting it by what each half is
allowed to do lets the reads overlap while the writes stay ordered:

- compute (ledger precheck, window scan, replay, manifest assembly) now
  runs concurrently across sources
- ingest stays strictly serial across sources AND instances. uploadAqFile
  derives box names from account ids the frac *registry* allocates as it
  goes, and that counter is registry-wide, so two instances ingesting at
  once would predict the same ids and all but the first would fail with an
  invalid box reference - the same reason the SDK refuses to parallelize
  the batches within one upload.

Compute returns its per-source outcomes rather than pushing onto the run
context, so the report still reads the same on every run (pMap answers in
input order).

Also, on the same path:
- per-instance ledger prechecks fan out; a multi-instance source (reti runs
  one per validator) spent a serial round trip per instance before any scan
- plugins are built once per run and shared by stages 1 and 3; reti was
  resolving every validator's pools twice
- the manifest genesis hash is read once per run, not once per instance
- stage/phase timings behind the debug flag, so this is measurable at all