#3429 Manual: make behavior the primary term and command spelling

Problem

behavior is the product term and swamp behavior is the preferred CLI tree (#3331, #3409 and #3410). Stored formats and legacy swamp model commands remain compatible by design (#3334 and #3338). #3412 moved the README, design records, agent constraints and skills to the preferred spelling, but the public manual has not followed.

An audit finds 38 manual pages with either legacy command examples or model-first conceptual language. Its principal entry points actively teach the old term:

• explanation/models-types-and-methods, explanation/how-swamp-works, and how-to/core-operations frame models as the central primitive.
• how-to/core-operations/create-and-run-a-model teaches only swamp model … commands, including the superseded model method run form.
• reference/model-definitions, reference/extensions/model, and the glossary define model/model definition/model type as the public vocabulary.
• Extension authoring guides and tutorials create extensions/models/ files, export const model, and models: manifests even though behavior-spelled authoring is supported.

This makes a new reader learn the deprecated product vocabulary immediately after the CLI and skills have moved to behavior.

Direction

Make behavior the manual's ubiquitous product term:

• behavior; behavior definition; behavior type; behavior output; behavior method;
• swamp behavior run <behavior> <method> for a method invocation;
• swamp behavior create|get|edit|delete|validate|evaluate|search|cancel, swamp behavior describe|history|output, and swamp behavior type … for the corresponding CLI operations;
• behavior-spelled workflow, extension and data prose; and
• extensions/behaviors/, export const behavior, and behaviors: in new extension-authoring examples.

Retitle and cross-link the core explanation, core-operation how-to, definition reference, extension interface reference, glossary, tutorials, and dependent reference/how-to pages so behavior is what readers see in navigation, search, SEO metadata and prose. Add a short compatibility note at the primary entry point: swamp model … remains a supported legacy spelling.

Use behavior-named public manual slugs for the renamed primary pages, and add 301 redirects from their existing model-named URLs in MANUAL_REDIRECTS. Update all internal links to the canonical new URLs. This keeps bookmarked links, external references and existing telemetry paths working while navigation and the sitemap advertise the new names.

Compatibility boundary

This is documentation and site routing work, not a change to the CLI or stored contracts. Keep model when it is a literal compatibility or protocol name:

• legacy swamp model … commands, in the compatibility note only;
• existing models/ and .swamp/ layout;
• serialized JSON, error, telemetry, audit and protocol identifiers such as modelName, modelType, model_not_found, and model.method.run;
• CEL's model.*, model() and model.method() namespaces; and
• TypeScript API identifiers such as context.runModel() and compatibility details of pulled/pushed extension archives.

Explain these as compatibility identifiers where they appear in user-facing material; do not mechanically rename code tokens or claim that old repositories must migrate. The existing behavior-spelled extension and workflow formats are additive, while Swamp continues to normalize/write the compatible model form.

Acceptance

• The manual's main navigation, titles, descriptions, first-party tutorials and copy-pasteable examples make behavior the primary term and command spelling. model method run examples become behavior run.
• The four core pages are replaced by behavior-named counterparts and all affected links point to those canonical pages: models-types-and-methods, create-and-run-a-model, model-definitions, and extensions/model.
• Their legacy model-named URLs return 301 redirects to the behavior-named pages, with route tests covering each redirect.
• Extension authoring examples use extensions/behaviors/, export const behavior, and behaviors:; compatibility/reference sections accurately describe the still-supported model forms and the formats Swamp writes.
• The glossary establishes behavior as the product term and distinguishes it from the literal model compatibility identifiers above.
• Add a focused manual terminology regression test (or extend the current content terminology test) that rejects new model-first commands and headings outside an explicit, narrow compatibility allowlist. It must not flag CEL, JSON/API field names, telemetry/action names, or code identifiers.
• Verify documented CLI forms against the released CLI help/schema and run the manual route/content tests plus deno task check.

Non-goals

Do not remove swamp model, migrate stored repositories, rename serialized fields, or alter telemetry/serve/CEL contracts. Those compatibility guarantees are already established by #3334, #3338, #3409, #3410 and #3412.