fix(js): base confidential-mint supply on the confidential ciphertext

[latent-9]

Summary

buildConfidentialMintProofPlan derives the new supply from the AES
decryptable_supply, but pairs the resulting commitment with a ciphertext
that encrypts confidential_supply + amount. The
CiphertextCommitmentEqualityProof only verifies when the ciphertext and the
commitment encode the same value, so the mint is rejected on-chain whenever
the two supplies differ:

1. After an apply-pending-burn: ApplyPendingBurn advances the ElGamal
   confidential_supply but does not re-encrypt the AES decryptable_supply.
2. At initialization: a nonzero InitializeMintData.decryptable_supply
   diverges from the zero confidential supply before the first mint.

The on-chain mint hard-requires the new supply ciphertext to equal
add_with_lo_hi(confidential_supply, amount) and verifies the equality proof
against that value, so the only consistent plaintext for the commitment is
the confidential supply, not the decryptable one.

Change

Derive currentSupply by decrypting confidentialSupply with the supply
ElGamal keypair. The resulting newDecryptableSupply also re-syncs the AES
decryptable supply in the same instruction, matching the manual
getUpdateConfidentialMintBurnDecryptableSupplyInstructionFromSupply call
that was previously required after every burn.

Test

Adds a regression test that mints, burns, applies the pending burn (without
any manual decryptable-supply re-sync), and mints again. It verifies the
second mint succeeds and that the decryptable supply tracks the encrypted
supply.

[latent-9]

Update: after reproducing the audit locally, the advisory that actually fails the job is RUSTSEC-2026-0258 (h2 0.3.26, unbounded empty DATA frames, published 2026-08-17). The h2 0.3.x line has no fixed release, the fix requires h2 >= 0.4.16, so there is no applicable patch for this lockfile yet.

RUSTSEC-2026-0173 (proc-macro-error2 unmaintained) shows up as an allowed warning, not a blocker.

This is unrelated to the changes in this PR and would fail on main too, since the last successful audit run was 2026-08-13.

Pushed 1feea7b adding both advisories to the ignore list in the Makefile audit target:

--ignore RUSTSEC-2026-0173
--ignore RUSTSEC-2026-0258

Verified locally that make audit passes with these two entries.