An admin makes gift codes in the forge: a code gives a plan for free, with or without a payment provider #11157

Why. The owner gives friends free forges. Today that is a Stripe promotion code made outside the forge. A code should be the forge's own thing, so it works for an operator with no payment provider at all, and the owner makes one in two clicks.

What.

• Admin Billing page, a Codes section: Make a code asks for the plan it gives, how many times it can be used (default 1), an optional note ("for Mark") and an optional expiry. The code is short, typed easily and unguessable (e.g. forge-7kq4-m2xp), shown with a copy button and a ready-to-send link …/?code=<code>.
• The list shows each code: plan, note, used of limit, who redeemed (forge name, when), and one action, Revoke. Revoking stops new uses; forges already made keep their plan unless the admin changes it (the grant from #11134).
• Redeeming: the home form (#11153) and /pricing (#11138) take a code — from the link it is already filled in and the page says "A gift from <forge's owner>: a <plan> forge, free." The forge is made on that plan with an entitlement whose source is code:<id>; no checkout, no card, whatever the provider.
• A wrong, used-up, expired or revoked code is said plainly on the same screen, with the normal ways forward still there.
• API and an MCP tool (dryRun by default) do the same as the page. Every make, redeem and revoke is in the audit trail. Codes are stored hashed; the plain code is shown once to the admin and lives in the link they send.
• Redemption is rate-limited per client like other visitor actions, so codes cannot be guessed by trying.

Acceptance. Tests: make → redeem → forge on that plan; a second use of a one-use code is refused; revoked and expired codes are refused; provider none and provider stripe both redeem without any call to the provider. The Codes section fits the first view of the Billing page without scrolling for ten codes or fewer.