docs: ecommerce-as-plugin ADR + README plugins section

[thunpisit]

Summary

Proposes an official plugin mechanism for Khao Pad and ships the ADR for the first plugin: `@khaopad/plugin-shop` — small ecommerce for Thailand-first sites using BeamCheckout.

Why

The `codustry/bactrack-website` fork (live at bactrack.in.th) has a working, production-tested shop implementation with:

• 8 D1 tables (`carts`, `cart_items`, `orders`, `order_items`, `discount_codes`, `discount_redemptions`, `affiliates`, `affiliate_referrals`)
• BeamCheckout integration — PromptPay QR + credit card 3DS + LINE Pay + TrueMoney
• Public store surface (cart / checkout / pay / order / lookup)
• CMS admin at `/cms/shop/{orders,discount-codes,affiliates}`
• Money in integer satang (never float)
• Discount codes + affiliate referrals + receipt emails via Resend
• Product catalog as static TypeScript (not D1 rows) — perfect fit for small catalogs (5-50 SKUs)

The whole thing sits cleanly beside Khao Pad's v2.0 surface — never modifies core tables, never assumes a shop exists in any core code path. That structure is exactly what a plugin should look like. Formalizing it lets:

• BACtrack become maintainable via `pnpm update` instead of manual upstream sync
• Any future Codustry client site add commerce without a fork
• Core Khao Pad stay lean for the 90% of sites that never need ecommerce

What's in this PR

• `docs/adr/0001-shop-as-optional-plugin.md` — full ADR (context, decision, plugin contract, schema list, routes, settings card, rationale, consequences, roadmap through v0.3, alternatives considered, open questions)
• `README.md` — new "Plugins (proposed for post-v2.0)" section between v2.0 and Platform fundamentals; describes the shop plugin at a high level and links the ADR

Explicitly not in this PR

The plugin mechanism itself. This PR is docs-only — an ADR to socialize the design before writing plugin infrastructure code. If reception is positive, next PR would be:

1. Plugin loader (schema concat + route mount + sidebar merge + audit + webhook + settings + i18n)
2. `@khaopad/plugin-shop` v0.1 based on the ADR

Estimated ~2 weeks focused work for both.

Test plan

• Doc-only PR — no code changes, no build to verify
• Links check (all internal doc paths + external Beam docs URL)
• Feedback on the ADR before writing any plugin infrastructure

🤖 Generated with Claude Code

[thunpisit]

Triage as part of Phase 5D (#104).

Docs-only (README.md + docs/adr/0001-shop-as-optional-plugin.md), and GitHub reports its mergeability as UNKNOWN — the branch is old enough that it needs a refresh before the state is meaningful.

Still worth merging, with one caveat. The ADR argues shop belongs behind a plugin seam rather than in core, and that reasoning has held up: the plugin registration mechanism it anticipated now exists and is load-bearing ($lib/plugins/registrations, registerNavGroup). If anything the case is stronger than when it was written.

The caveat is that it is still marked Status: Proposed and dated 2026-05-03, while parts of it have since shipped. Merging it as-is records a proposal, not a decision. Before merging it is worth either promoting it to Accepted with a note on what has landed, or leaving it explicitly Proposed so nobody reads it as settled.

That is an editorial call about your own architecture record, so I have not rewritten it. Happy to do the status update and refresh if you want it.