feat(spec): make spec types and required sections configurable

[jamesaphoenix]

Context

Spec structure was hardcoded: five spec types with fixed required markdown sections, enforced in parseMdDocSync as a hard parse failure. Teams could not express their own documentation conventions, define new spec types, or tailor the prompts agents receive when a section is missing.

Key observation driving the design: no markdown heading is load-bearing. tx spec discover, invariant sync, and FCI scoring locate embedded ```yaml blocks by fence and top-level key anywhere in the body, never by heading. What is load-bearing is the frontmatter contract and the block schemas, and those stay fixed.

What changed

Config-driven sections. Required sections now come from [spec.types.*] in .tx/config.toml. Each section carries a description (what belongs under the heading) and its own message (the lint prompt when it is missing); each type carries severity (error|warn|off), subdir, and an optional template file.

[spec.types.prd.section.problem]
heading = "Problem"
description = "The user or system problem being solved, with evidence."
message = "{name}: PRD is missing '# Problem'. State the problem first. {description}"

User-defined spec types. A [spec.types.rfc] table is enough to make tx doc add rfc scaffold, store, and lint that type like a built-in. DocKindSchema/MdSpecTypeSchema become validated identifiers instead of literal unions, and migration 048 drops the docs.kind allow-list (following the 046 rebuild pattern — FK-off, self-reference written with the final table name).

Lint-only enforcement. validateRequiredSections is gone from the parser. A missing heading no longer blocks tx doc add/update/sync/render or drift detection; tx spec lint reports it under a new Required Sections group at the configured severity, plus a Spec Type Config group for advisory warnings.

Bundled defaults. tx init writes the built-in definitions into every scaffolded config as active, editable TOML, generated from DEFAULT_CONFIG itself so the file and the code cannot drift (round-trip test). Re-running tx init on an existing project appends the new block additively via upgradeConfigToml.

Config-aware skills. Generated skills embed this project's headings, descriptions, and resolved lint prompts via a marker block, and a new spec-doc skill covers custom types. Skills also point at tx spec types --json as the live authority between syncs.

New commands. tx spec types [--json] (the machine-readable contract) and tx doc template <type> (preview a scaffold without writing).

Verification

• Full suite: 5128 passed, 0 failures. Typecheck and lint clean.
• New: test/unit/spec-type-registry.test.ts (13), test/unit/spec-section-lint.test.ts (12), test/integration/spec-types-config.test.ts (14 numbered CLI scenarios), plus 14 added to toml-config.test.ts.
• doc-schema-validation scenarios 2, 5, and 10 were inverted from asserting parse rejection to asserting creation plus a lint finding.
• Backward compatibility: a config with no [spec.types.*] resolves to the built-in defaults, asserted by a deep-equality round-trip test.

Specs

specs/prd/configurable-spec-types.md and specs/design/configurable-spec-types-design.md (11 invariants, all linked to tests via tx spec discover).