feat(server): add Hostinger VPS provisioning and cloud tokens

[andrasbacsai]

Summary

• Hostinger as a cloud provider. coolify cloud-token create --provider hostinger now works. Validation and help text list Hostinger alongside Hetzner, DigitalOcean and Vultr.
• New coolify server hostinger command tree:
  • data-centers, catalog (alias plans), templates, ssh-keys and post-install-scripts take <cloud_token_uuid> and list the options Hostinger offers.
  • catalog prints one row per plan and billing period. Its item_id column is the value to pass to --item-id. Prices are in cents and include the first-period price.
  • SSH key contents are hidden unless you pass --show-sensitive.
• coolify server hostinger create buys a VPS and adds it to Coolify as a server:
  • Required flags: --cloud-token, --item-id, --data-center-id, --template-id, --private-key.
  • Optional flags: --name, --enable-backups (default false, because backups cost extra), --ssh-key-ids, --post-install-script-id, --validate.
  • This is a paid purchase that renews until you cancel it, so the command asks for confirmation. Pass -f/--force to skip the prompt. Declining, an empty answer, or EOF sends no request.
• Protection against duplicate purchases:
  • The create request is sent exactly once, even when the API returns 5xx or 429. The new api.Client.PostOnce handles this.
  • A 202 response means Hostinger is still processing the payment and no server has been created yet. The command treats this as an error and warns you to check your Hostinger account before retrying.
  • On a 5xx error that includes hostinger_virtual_machine_id, the command warns that the VM may already have been bought.
  • A 422 error lists the details for each field. A 429 error shows the Retry-After value.
• API client: api.Error now also stores the raw response body (Body) and the Retry-After header (RetryAfter), so callers can show structured error details.
• Docs: README, llms.txt, llms-full.txt and the embedded docs are updated.

Testing

• Unit tests cover catalog flattening, payment-pending detection and provider validation.
• Service tests run against a mock API. They cover the query parameters for each option endpoint, the request body (including which optional fields are left out), and error handling for 202, 422, 429 and 5xx with exactly one request each time.
• Command tests cover required flags, the confirmation flow (accept, decline, EOF, --force), and hiding SSH keys in table output.