Add one useful policy recipe with allowed, denied and look-alike examples #18

Why

The built-in packs are starting points. A developer adapting a policy needs to
see a legitimate workflow that remains possible, the exact action the rule
blocks, and an innocent look-alike that must not be accidentally blocked.

Propose one bounded recipe before coding. A good first scope is a named MCP
tool with structured input, such as allowing email drafts while denying send,
or restricting an explicit database operation field to reads. Use a synthetic
tool schema or an openly documented schema; include the tool/version it models.
Do not expand shell substring rules into a promise of process isolation.

Scope

• Add one short Cedar recipe and explain the tool/resource/context fields it
  relies on. Prefer structured fields over guessed natural-language intent.
• Include a permitted example, a denied example and a harmless look-alike
  example. For instance, a draft body containing the word “send” should not be
  treated as the send operation.
• Include the missing or wrong-typed required field case and state its expected
  behavior. Keep any default allow/deny assumption explicit.
• State a meaningful coverage limit, such as alternate tools or direct API paths
  that this recipe does not govern.
• Evaluate the examples through the real Cedar evaluator. Do not duplicate the
  expected decision in a mock evaluator.

Likely files

• docs/local-gateway.md or a small linked guide under docs/
• policies/cedar/ for the documented recipe
• A focused test alongside src/policy-packs.test.ts or
  src/cedar-action-model.test.ts, following their existing conventions

Done when

1. All four cases run against the documented policy bytes and the declared action
   model; the allowed and harmless cases remain usable.
2. The denied case names the matching rule with a useful @id and @reason.
3. The guide shows the exact input schema, commands and expected decisions.
4. npm run build, the focused tests and npm test pass.

Keep this separate from changing the default starter policy or automatically
installing rules for every user. Report an exploitable bypass privately through
SECURITY.md; this issue is for an additional documented recipe.