cfs validate-toc — honour project rule configuration and per-artifact-kind TOC options

[Oleg67]

cfs validate-toc — honour project rule configuration and per-artifact-kind TOC options

Part of #140. Depends on #174. Closes #53.

Context

cfs validate-toc reads no configuration at all: it parses files, --max-level, --max-section-lines and --verbose, and nothing else (skills/studio/scripts/studio/commands/validate_toc.py). Every Markdown file with headings and no Table of Contents is therefore an error with no way to disable or scope the rule — the problem reported in #53, where a run across a docs tree flagged 23 files that have no TOC by design.

The artifact pipeline already has a per-kind gate that the standalone command cannot see: validate_artifact_file runs the TOC phase only when toc = true in the kit's constraints (skills/studio/scripts/studio/utils/constraints.py:1866). That same phase hardcodes max_heading_level=3 (_validate_artifact_toc, utils/constraints.py:1158), even though validate_toc() is fully parameterised and the standalone command exposes both knobs — so the depth rule #141 wants relaxable is unreachable from cfs validate.

Scope

• Inside a Studio project, validate-toc loads the context, maps each path to its registered artifact kind, and applies the severity policy from cfs validate — kit-supplied and project-level severity configuration, and one report contract #174: toc-missing set to warning is reported and the run exits 0.
• Outside a project, behaviour is unchanged. Explicit CLI flags always win over configuration.
• TOC options become a sibling table so they can be set per artifact kind:

[artifacts.PRD.validation.toc]
max_level = 3
max_section_lines = 300

The existing toc boolean keeps its type. _parse_kind_toc rejects a non-boolean and fails the whole constraints file, so widening that key would make an older engine drop a newer kit's constraints entirely.

• _validate_artifact_toc reads the table instead of its hardcoded depth.
• The TOC rules get their first documentation: nothing in guides/ currently describes toc-missing, toc-stale, the anchor and coverage rules, or the JIT-readiness warnings.

Acceptance criteria

1. A project sets toc-missing to warning; cfs validate-toc reports the finding and exits successfully. (cfs validate — Severity Model: Warnings, Not Only Errors #140 AC1, closing the general case behind validate-toc: no way to disable/scope the toc-missing rule (hardcoded, ignores config) #53)
2. Without that setting, the same run exits 2 as it does today.
3. A kit sets max_level for one artifact kind and cfs validate honours it instead of the hardcoded 3.
4. Running outside a project, and running with explicit flags, behave exactly as before.
5. cfs validate-toc over this repository's own guides stays green.

Delivery

One PR, feat(validate-toc): honour project severity and per-kind TOC options, closing this issue and #53.