fix(payments): normalize public card method

[Jesssullivan]

What changed

• normalize the public Stripe booking method to card at the package boundary
• keep the legacy stripe alias readable internally during transition
• route unsupported card and venmo selections to error instead of falling through to manual completion
• emit public payment options through shared helpers so drawer, checkout, and registry stay aligned
• teach the booking pipeline factory to resolve Stripe-backed flows through the public card id

Why

MassageIthaca surfaced a real divergence: Acuity capabilities exposed card as card, while scheduling-kit still branched on stripe in the hybrid drawer and registry. That let card flows miss Stripe checkout and fall through into incorrect local completion paths.

Impact

This makes scheduling-kit the owner of the canonical public card payment id. Consumers can keep using card across page and drawer shells while the package preserves internal Stripe processing semantics.

Validation

• /Users/jess/git/scheduling-kit/node_modules/.bin/vitest run src/tests/unit/core/pipelines.test.ts src/tests/unit/core/wizard-pipeline.test.ts src/tests/components/hybrid-checkout-state.test.ts tests/e2e/payment-selector.test.ts src/tests/hybrid-checkout-capabilities.test.ts
• full svelte-check remains noisy in this repo due pre-existing unrelated errors, so validation for this slice stayed focused to the affected payment controller and selector tests

Root cause

Public payment-method ids and internal adapter names were leaking across the same boundary. The registry, older checkout path, and hybrid drawer were not all consuming the same contract.

[Jesssullivan]

Triage refresh 2026-04-25:

• Title cleaned up to remove stale attribution prefix.
• PR is still draft and currently dirty against main.
• The underlying public-method issue is not obviously resolved on current local main: the hybrid drawer still branches on paymentId === "stripe", so do not close this as superseded without a focused rebase/review.
• Local scheduling-kit has a large in-progress docs/toolchain/boundary worktree; preserve that work before attempting to rebase this branch.

Recommended next action: rebase/rewrite this as a small payment-contract PR after the current package boundary/docs branch lands, then run the affected payment selector/hybrid checkout tests.