`create_token` has no `max_supply` parameter, unlike `create_tokens_batch`

[Ejirowebfi]

🔴 Critical · contracts/token-factory/src/lib.rs:253-385 vs :34-41,387-473

Description

BatchTokenParams (used only by create_tokens_batch) includes pub max_supply: Option<i128>, enforced both at creation time (validate_batch_params rejects initial_supply > cap) and at mint time (mint_tokens checks MaxSupplyExceeded). The single-token path, create_token, has no equivalent parameter — every token created through it has max_supply: None hardcoded at line 358, meaning it is uncappable for the lifetime of the token. A creator who wants a supply-capped token is forced through the batch API even for a single token, which is a confusing, undocumented requirement, and any UI or integration built naively against create_token alone can never offer this safety feature to end users.

Tasks

• Add an Option<i128> max_supply parameter to create_token (and create_token_inner), applying the same cap <= 0 || initial_supply > cap validation currently duplicated in validate_batch_params.
• Factor the shared validation (name/symbol/decimals/max_supply bounds) used by both create_token_inner and validate_batch_params into one function to eliminate the current logic duplication and prevent the two paths from drifting further apart.
• Update frontend/src/components/CreateToken.tsx and the corresponding service call in frontend/src/services/stellar-impl.ts to expose an optional max-supply field on the single-token creation form.
• Update docs/contract-abi.md's create_token signature and the README's Contract Functions section to reflect the new parameter.
• Since this changes the on-chain function signature, document the required upgrade + client-version coordination in the PR description (old clients calling the new contract will fail argument decoding).

Acceptance Criteria

• create_token accepts an optional max_supply and stores it in the resulting TokenInfo, verified by a new test.rs case.
• mint_tokens already enforces MaxSupplyExceeded off TokenInfo.max_supply — a test confirms this now also triggers correctly for tokens created via the single-token path (not just batch).
• create_token rejects initial_supply > max_supply with InvalidParameters, mirroring validate_batch_params.
• Frontend CreateToken form round-trips a max-supply value end-to-end against a local/testnet deployment.