feat: support emdash 0.28

[cavewebs]

Summary

Upgrades DashCommerce from emdash 0.6.0 to 0.28.1 (22 minor versions) and
propagates the change across the plugin, starter template, and demo build.

Changes

@dashcommerce/core

• sandbox-entry.ts builds the plugin via native definePlugin (single-arg
  RouteContext handlers) instead of adaptSandboxEntry. In 0.28
  adaptSandboxEntry flattens routeCtx.request to {url,method,headers}
  with no body, which would break the Stripe webhook.
• Capability names updated to the current vocabulary (network:request,
  content:read, content:write, media:read, users:read).
• emdash peer range → >=0.28.0 <0.29.0.

emdash patch (patches/emdash@0.28.1.patch)

• Plugin route handlers may return a raw Response (apiSuccess would
  serialize it to {} and drop Set-Cookie).
• Request body is cloned before parsing and ctx.request is left
  unguarded, so the Stripe webhook can read raw bytes for signature
  verification.

Starter

• src/worker.ts + wrangler.jsonc triggers.crons so plugin cron
  (abandoned-cart recovery, dunning, stock-lock sweeps) runs on Cloudflare.
• Regenerated emdash-env.d.ts.

Verification

• Monorepo typecheck / build / tests: 0 errors, all packages build, 84/84
  tests pass.
• Starter builds for Node and Cloudflare; generated entry.mjs bundles
  emdash's scheduled() handler with the cron trigger.
• Dev server: public route Response passthrough, Set-Cookie forwarding,
  and ctx.input bodies all confirmed.
• Stripe webhook: a fake signature returns 400 Invalid signature,
  confirming the raw body is read (no "body already read" crash).
• Seed validates and applies cleanly on 0.28.

Not covered here

The Cloudflare demo redeploy (bun run cf:deploy) — build artifacts are
correct, but it needs a live wrangler deploy + a check that the cron
trigger fires.

this should now fix the #15 issue