feat: guide account setup from the credential modal and README

[eitanp461]

Summary

Someone installing this node without a Cloudinary account had nowhere to start: the credential modal opens straight onto Cloud Name, and its Docs link pointed at the upload API reference — which never says where keys live. This adds setup guidance at the point of confusion and promotes Claimable Cloud provisioning as the fast route to working credentials.

Changes

• Credential setup notice. A notice property, first in the credential, linking to free signup and the Console API Keys page, plus the Claimable Cloud route via "ask an agent to run npx @cloudinary/cloud" — with the two caveats that matter in n8n stated inline (delivery is IP-restricted until claimed; unclaimed clouds expire in 24h).
• README auth section restructured into two explicit paths: the Console path first (signup → Settings > API Keys → copy cloud name/key/secret), then the agentic Claimable Cloud path. Also corrects the old step 2, which told every reader to click + Generate New API Key — a new account already ships with an active key, and the Console label is Generate New Access Key.
• Credential docs links repointed from image_upload_api_reference to developer_onboarding_faq_find_credentials, in both documentationUrl and the codex credentialDocumentation, so the modal's Docs link answers the question it's actually asked.
• Version bumped to 0.2.2 for the PR-check gate.

Notes

Provisioning is deliberately not exposed as a node operation. Cloudinary documents the endpoint as "a one-off call that an agent makes… not an API to integrate against in code," and it fits n8n's execution model badly on four counts: delivery_ips blocks media at the CDN edge for every address except the ones registered at provisioning time, so the secure_urls our Transform ops build wouldn't load for anyone else; unclaimed clouds and their assets are deleted after 24h; api_secret would land in execution data and run logs; and every re-run or input item would provision another cloud into a per-IP rate limit. No n8n community node provisions its vendor's own SaaS account — Vercel's Claim Deployments and Neon's Claimable Postgres both expose this primitive through API/CLI/MCP for the building platform, never as an end-user automation step.

A notice is also the only affordance available here: n8n's buttonConfig.action supports only askAiCodeGeneration, so a click-to-provision button in the credential modal isn't buildable. Notice content is sanitized to <a>/<ul>/<li>, which is why the command appears in quotes rather than a <code> tag.

Version collision: this takes 0.2.2, since #12 already claims 0.3.0. Whichever lands second needs a re-bump.

How to Test

npm run lint && npm run build && npm test

Then load the built node into a local n8n:

npm link
mkdir -p /tmp/n8n-claimable && cd /tmp/n8n-claimable && npm init -y
npm link n8n-nodes-cloudinary
N8N_CUSTOM_EXTENSIONS="$PWD/node_modules/n8n-nodes-cloudinary" n8n start

Add a Cloudinary node → Create new credential, and confirm: the notice renders above Cloud Name as prose; all three links open in a new tab; the command shows as plain text with no stray markup; and the header Docs link lands on the find-credentials FAQ.

Verified locally: lint clean, build compiles, 242 tests passing, and backward-compatibility-check reports 0 breaking changes with setupNotice detected as an additive credential parameter.

🤖 Generated with Claude Code

[eitanp461]

Before

After