fix(payin): skip Cardano pay-in check when no Tatum API key is configured

[Danswar]

Problem

CardanoStrategy.checkPayInEntries runs every minute and always polls (it unconditionally includes the Cardano payment deposit address), so on an environment without a working Tatum key every cycle logs an ERROR. On dfxdev this is currently ~60 errors/h (AxiosError: Request failed with status code 402 — the Tatum plan is out of credits).

Change

Same pattern as the exchange-credentials fix (#3859): not configured → skip + warn once; configured but rejected → still ERROR.

• CardanoClient.isConfigured — true when cardanoTatumApiKey (TATUM_API_KEY) is set; the client is the credential owner (httpConfig() sends it as x-api-key)
• delegated through CardanoService / PayInCardanoService (pure-delegation style of those services)
• the cron skips with a single WARN when unconfigured; the on-demand pollAddress path is untouched, so an actual use without a key still surfaces loudly

Design notes (alternatives considered)

• Cron still ticks and early-returns — intentional. This mirrors the framework's own DISABLED_PROCESSES semantic in DfxCronService.wrapFunction (fires every tick, checks, returns). Conditionally not registering the job would deviate from that design for no measurable gain (an empty tick is one property read per minute).
• Other TATUM_API_KEY consumers are deliberately not guarded. Solana/Tron strategies are webhook-driven and TatumWebhookService only calls Tatum on demand (subscription creation) — none make unprompted calls, so none spam logs. Guarding them would silently no-op real usage paths instead of failing loudly when actually used.
• DISABLED_PROCESSES=PayIn is too coarse (disables pay-in for all chains), and a new per-chain Process value would grow a shared enum plus require env wiring per environment — more surface, same outcome, and not self-healing.

Effect

Dev environments need no Tatum key at all: after removing TATUM_API_KEY from the dev env, the Cardano bucket goes to zero (one WARN per process start). Prod behavior is unchanged — a set-but-broken key (e.g. quota exhausted) keeps erroring, which is the signal we want there.

Verification

• tsc --noEmit clean
• payin test suites: 3 suites, 58/58 pass