feat(core): support threshold and key-list keys in account creation

[jmgomezl]

Closes #1087

What

create_account_tool accepts a single publicKey, and KeyList / ThresholdKey appear nowhere in packages/core. An agent therefore cannot create any multi-signature account — no treasury, no m-of-n escrow, no shared account with several approvers — even though multi-signature keys are a first-class Hedera primitive.

This adds two optional parameters to createAccountParameters:

parameter	meaning
publicKeys: string[]	the members of a multi-signature key
threshold?: number	how many of them must sign (m-of-n)

Without a threshold the resulting KeyList requires every key; with one, any threshold of them suffices.

How

• HederaParameterNormaliser.buildMultiSigKey() builds the KeyList, validating that a supplied threshold is within 1..publicKeys.length.
• normaliseCreateAccount short-circuits the single-key resolution when publicKeys is present, so no mirror-node lookup happens in that path.
• createAccountParametersNormalised already accepted any Key, so HederaBuilder.createAccount is unchanged.

Why it is safe

• Purely additive. Existing single-key behaviour, including operator and mirror-node fallback, is untouched; all 631 existing core unit tests pass.
• No private key material crosses the tool boundary, so nothing sensitive enters an LLM's context.

Tests

Unit (create-account-params-normalization.unit.test.ts) — 7 new:
key-list without threshold, m-of-n with threshold, precedence over publicKey, no mirror-node lookup when keys are supplied, rejection of thresholds of 0 and > n, and the unchanged single-key fallback.

Integration (create-account.integration.test.ts) — 3 new: creates both key shapes on testnet and asserts the resulting account key through the mirror node, plus the invalid-threshold path.

unit         13/13 passed (create-account normalisation)
core unit    631 passed
integration   9/9 passed against testnet
prettier     clean
eslint       clean

(tests/unit/utils/decimals-utils.unit.test.ts fails on a clean checkout of main as well — unrelated to this change.)

Known limitation

A flat publicKeys + threshold cannot express a nested key such as KeyList[ keyA, ThresholdKey(2, [k1,k2,k3]) ]. A recursive schema would cover it but complicates the JSON Schema exposed to LLM tool definitions, so this PR deliberately covers the flat cases first. Happy to explore nesting if you would prefer that shape.

Scope

Account creation only. The same gap exists for token admin/supply/freeze keys, updateAccount and topics — glad to follow up there if this shape is agreeable.