Fix: Add missing validators on DTO fields rejected by whitelist validatiib

[Jehosephat]

The mint error is the third face of the #811 strict-whitelist rollout, but a new variant: this time it's not legacy state — it's a property that never had any class-validator decorator. Whitelist validation only recognizes properties that carry at least one validator decorator, so an undecorated property is "unknown" even on its own class.

FetchTokenMintConfigurationsResponse.results (chain-api/src/types/mint.ts) had only @jsonschema — no validator. The chaincode builds that response via createValidDTO, so every FetchTokenMintConfigurations call that returns a configuration has failed since #811 with exactly your screenshot's error: whitelistValidation: property results should not exist. I reproduced it in one line — even an empty results array throws. The "Use Mint Allowance" flow trips it because the JAPAN token has a mint configuration the UI fetches pre-mint; tokens without configurations wouldn't.

Fixes (uncommitted on fix/no-response-validation)

• mint.ts — results now has @ValidateNestedAllowUnknown({each: true}) + @type(() => TokenMintConfiguration): whitelisted, validated, and tolerant of legacy nested fields, consistent with the balance/token-class pattern.
• Systematic sweep for the whole class of bug: I wrote a runtime checker that compares every exported class's declared properties (from .d.ts) against its class-validator metadata. It found and I fixed:
  • fee.ts — five KeyValueResult.key fields (fee payments, credit receipts, pending balances, threshold uses, chain key-values) with only @jsonschema → added @IsString(). These are latent (their responses aren't server-validated today) but identical landmines.
  • TokenSwapRequestInstanceOffered/Wanted.category — had @CHAINKEY but no validator while every sibling key has one; added @isdefined() (not @isnotempty, to stay safe for any legacy empty-string categories in state).
  • The only remaining flags are the GalaChainResponse/Success/Error envelope classes, which never pass through DTO validation — left alone deliberately.
• Regression test (chain-api/src/types/mint.spec.ts): builds the response from a chain-read configuration including an unknown legacy field — fails with your exact error pre-fix, passes post-fix.