fix(pqc): harden PQ auth sig checks and wallet UX

[Federico2014]

What does this PR do?

Hardens PQ auth signature handling and tightens wallet/CLI UX, and lays the groundwork for adapting getCanDelegatedMaxSize to the new pq_scheme field introduced in nile-testnet#53.

Note on getCanDelegatedMaxSize / pq_scheme: this PR only adds the proto field and the end-to-end pass-through plumbing (CLI/REPL option → WalletApi → ApiClient → proto). The scheme hint is not yet applied at runtime because Trident's ApiWrapper.getCanDelegatedMaxSize does not accept a PQScheme parameter, so ApiClient currently ignores it and the node returns the ECDSA-sized estimate (backward-compatible default). In other words, passing --scheme does not yet change the returned value — the option help, the REPL tip and the ApiClient/WalletApi TODOs all say so explicitly. The actual behavioral fix lands once the Trident SDK is updated (see Follow up).

Why are these changes required?

• PQ auth signatures (in Transaction.pq_auth_sig) do not bump getSignatureCount(), so existing guards that bail on getSignatureCount() != 0 silently invalidate a signed PQ transaction by rewriting raw_data.
• Trident's Chain.Transaction lacks the pq_auth_sig field (field 6), so PQ sigs are lost when rebuilding transactions (e.g. to inject fee limits) unless unknown fields are explicitly preserved.
• PQ keystores (seed-only) fail Wallet.validPassword because the ECDSA ciphertext/mac path does not apply.
• Falcon key derivation is architecture/JVM-dependent; users need explicit warning to back up the persisted key, not just the seed.
• CLI key material passed via --extended-private-key-hex is exposed in shell history and ps; --key-file / stdin is safer.
• getCanDelegatedMaxSize was hardcoded to an ECDSA-sized bandwidth estimate; for PQ accounts, the delegate transaction carries a much larger PQAuthSig (e.g. ML-DSA-44 ≈ 3.7 KB vs ~65 bytes ECDSA), so the returned max is too large — after delegating that amount, the account has no bandwidth left to send the delegate tx itself. This PR does not fix that yet; it adds the proto field and the pass-through API surface so the fix can land without a second wire-format change once the Trident SDK accepts the parameter. Until then the scheme is accepted but ignored.

Key Changes

Module	Change
TransactionUtils	setExpirationTime / setPermissionId bail when a PQ auth sig is attached; PQ_AUTH_SIG_FIELD_NUMBER exposed and shared with WalletApi
WalletApi	Preserve unknown fields when rebuilding deploy/trigger txs; include PQ sig bytes in bandwidth estimate; new getCanDelegatedMaxSize overload with PQScheme parameter (pass-through only)
Wallet	Route PQ keystores through a MAC-only validatePasswordPQ in validPassword (no key material decrypted, no signer constructed)
PQSchemeRegistry	Use DecodeUtil.addressPreFixByte + length guard in computeAddress
MLDSA44	Align BouncyCastle package paths with java-tron
ApiClient	New overload + TODO(trident-sdk): the PQScheme is currently ignored (no-op) pending Trident SDK support
api.proto	CanDelegatedMaxSizeRequestMessage gains PQScheme pq_scheme = 3
Client / WalletCommands / QueryCommands	Scheme-aware Falcon backup warning; --key-file / stdin import; --scheme on get-can-delegated-max-size (documented as a no-op for now); REPL 3rd param for scheme with a no-op note
README	Document Falcon backup caveat and --key-file import flow

This PR has been tested by:

• Manual Testing
• Compile (./gradlew compileJava)
• Full test suite (./gradlew test)

Follow up

• Update Trident SDK to accept PQScheme in its getCanDelegatedMaxSize API method, then wire pqScheme through ApiClient, pass the active wallet's scheme from WalletApi.delegateResource, remove the TODO markers in ApiClient.java / WalletApi.java, and drop the "no-op" notes from the CLI/REPL help.