docs: adopt Jupyter notebooks for all cookbooks

[MatthiasHowellYopp]

Summary

This makes Jupyter notebooks (.ipynb) the format for all cookbooks, in every language. Prose and runnable code live in one file, so a reader runs the cells as they read and CI runs the same code the reader runs. Jupyter has kernels for every language this repo uses (Python is built in; Go, TypeScript/JavaScript, and Java come from community kernels), so there's no need for a different format per language.

What changed in CONTRIBUTING.md

• Cookbook Format — new section: cookbooks are notebook series in any language. A short kernel table maps each language to its Jupyter kernel (ipykernel, gophernotes, tslab, IJava).
• Cookbook Content Requirements — the authoring rules (required files, chapter structure, mandatory elements, security callout, Valkey startup, How It Works, config reference) are now stated once and framed as notebook cells, so they apply to every chapter.
• Cookbook Structure — one language-agnostic layout: notebook chapters plus the support files a notebook can't carry (dependency manifest, docker-compose.yml, optional shared helper, .gitignore) in the same directory, with no separate sample/ subtree. Adds notebook content rules (cleared/reproducible outputs, no secrets in outputs, .ipynb nav links).
• CI Validation — cookbooks are validated by running every notebook end-to-end; a cell that raises fails the build.
• Sample guidelines reconciled with Vendor Neutrality — the default path must run for free (no paid account, credentials, or special hardware). Paid or specialized capabilities (e.g. a GPU or paid API) are optional, clearly-labeled extensions, never the only path.

Notes

• No cookbook content changes here. This is the policy and structure update only; cookbook PRs follow this convention.
• markdownlint passes on the changed content. The pre-existing MD060 table-style findings elsewhere in the file are unrelated and left untouched.

[Jonathan-Improving]

QA review — docs: adopt Jupyter notebooks for all cookbooks

Scope: single-file docs/policy change to CONTRIBUTING.md (+151/-72). No .ipynb, source, or GLIDE API code is added by this PR, so there is no notebook cell code to validate against the GLIDE SDK. The change is well-organized and the security posture is actually strengthened (explicit no-auth/TLS-localhost-only callout; "never commit secrets/tokens/machine paths in notebook outputs").

Verified independently:

• All 8 internal anchor links (#cookbook-structure, #cookbook-content-requirements, #notebook-content-structure, #vendor-neutrality, …) resolve to real header slugs — no broken cross-links introduced.
• All .ipynb/.md link references in the diff are illustrative relative examples, not real targets.

A few consistency gaps are worth resolving before merge (see inline comments). None are blocking.

Findings: 1 Medium, 1 Low–Medium, 1 Low, 1 Tidy.

---

Process note (transparency): the CAO orchestration server was unreachable during this run (port 9889 refused), so the specialized reviewer sub-agents, the independent Haiku nitpick-filter pass, and the independent spot-check audit could NOT be spawned. This review was conducted directly across all reviewer lenses (docs/domain, DRY, anti-pattern, link integrity, security) with grep-confirmed line numbers, but it lacks the independent multi-agent cross-check the full pipeline provides. Jira could not be searched (no Jira CLI/MCP access in this environment) and the PR links no GitHub issue, so upstream acceptance criteria were taken from the PR description only.

[Jonathan-Improving]

[Tidy — optional] New ### Directory Naming heading creates a duplicate slug.

This section adds a third ### Directory Naming heading (also under Demo Structure and Sample App Structure). GitHub auto-suffixes duplicate slugs (#directory-naming-1, -2), so no cross-link is broken today and nothing here targets these anchors. Purely a note: if a future doc links to a specific "Directory Naming" section, the suffixed slugs are brittle. No action required — recorded for awareness only.

[MatthiasHowellYopp]

Noted, thanks. I'm leaving it as-is: nothing links to those anchors today, and renaming the heading would be churn for no current benefit. Recording it here so we catch it if a future doc needs to deep-link a specific Directory Naming section.