fix: parametrize NFT serial in TokenReject.rejectTokens

[ValentinVPK]

Description:

TokenReject.rejectTokens hardcoded nftId.serial = 1, so the example could only ever reject serial #1 of each NFT collection — any other serial was unreachable, and the limitation was invisible to the test suite (it only ever minted one fresh NFT, which is always serial 1).

• Add an int64[] serials parameter to rejectTokens and use nftId.serial = serials[i] (mirroring cancelMultipleAirdrops / claimMultipleAirdrops)
• Update the existing test call sites to pass the new serials array
• Add a regression test that mints two NFTs and rejects serial #2, so the missing-serial limitation cannot silently return
• Fix two mintNFTToAddress calls in the test that were missing await (they returned Promises and "worked" only because the reject was hardcoded to serial 1)

Related issue(s):

Fixes #123

Notes for reviewer:

This is a breaking ABI change — rejectTokens gains a parameter, so its selector changes. That's inherent to the fix (the serial must be caller-supplied). The serials array is expected to be parallel to nftAddresses; there's no explicit length guard, matching the sibling multi-airdrop helpers (out-of-bounds already reverts at the EVM level).

Verified: npx hardhat compile clean (64 files); the rewritten test passes Prettier and ESLint. The regression test asserts the second minted serial is 2 (setupNft creates a fresh collection and does not pre-mint, so sequential mints yield 1 then 2) and rejects serial #2 — which the previous hardcoded-1 code could not do. The acceptance suite runs against a live Hedera node (solo), so runtime confirmation is via CI, not local.

[swirlds-automation]

🎉 This PR is included in version 0.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀