Add standalone Partiful Card creation, editing, sharing, and deletion

[KalebCole]

User scenario

I want an agent to create a Partiful card, preview its structured content, share its public link, edit it later, and delete it when I no longer want it published.

Problem

Partiful Cards are a standalone product surface, but the CLI has no cards namespace, endpoint contracts, schemas, or tests. Event posters and comments cannot substitute for cards because cards have their own ownership, public page, appearance settings, and lifecycle.

Verified product and API facts

Current Partiful bundles expose createCard, updateCard, deleteCard, createCardComment, and deleteCardComment. The observed card model includes:

{
  "title": "...",
  "description": "...",
  "image": {},
  "displaySettings": {
    "theme": "...",
    "effect": "...",
    "titleFont": "..."
  }
}

The product supports built-in image search/categories, JPEG/GIF/PNG upload, title, note, theme or custom hue, title font, animated effect, editing, deletion, and sharing. Sender identity comes from the authenticated profile in the observed composer. Routes exist for card creation, public card display, and editing.

No card mutation was performed during investigation. Exact card reads/listing, upload details, defaults, constraints, and public URL construction still need verification.

Proposed experience

partiful cards create --title "Thank you" --description "Great night"
partiful cards create --title "Congrats" --image ./card.gif --theme sunset --dry-run
partiful cards get <cardId>
partiful cards update <cardId> --effect confetti --dry-run
partiful cards delete <cardId>
partiful cards share <cardId>
partiful schema cards.create

Creates and updates should return normalized card state plus the canonical public URL when the server provides enough information to construct it safely. Updates must patch only supplied fields.

Scope boundaries

• Cards are not events, event posters, profile cards, or event comments.
• Use the authenticated account as sender identity unless further API evidence proves an explicit override is supported.
• Do not invent defaults for theme, effect, font, image shape, or share URLs.
• Validate local media before upload. --dry-run must not upload or mutate.
• Deletion needs confirmation and read-back or a verified not-found state.
• Card comments are a separate follow-up unless required to make card reads faithful.

Discovery needed

Verify the canonical create/get/list/update/delete payloads and response shapes, image upload endpoint and upload type, media limits, default display settings, partial-update behavior, ownership checks, public URL format, deletion semantics, pagination, and whether cards can be private or unpublished.

Acceptance criteria

• Users can create, read, update, delete, and obtain a canonical share URL for owned cards.
• Updates patch only supplied fields and preserve all other content and display settings.
• Local images are validated before network activity.
• --dry-run performs no upload and no card mutation.
• Successful create/update operations are read back and returned as normalized state.
• Listing or reading zero cards is a successful empty state.
• Ownership, validation, upload, permission, not-found, and read-back mismatch errors are structured.
• Normal output does not expose authentication metadata or internal user IDs.
• CLI help, schemas, unit tests, and a controlled create/read/update/delete E2E with cleanup ship together.

Related work

Closed #5 covers event images and posters. #20 covers event comments and uploaded event photos. Neither represents the standalone Card lifecycle.