Design & implement plugin extensibility — `x-` prefix (§21)

[AlexChesser]

Summary

Design and implement the x- prefix extensibility mechanism for custom step properties and pipeline extensions.

Parent issue: #105 — Tier 4, Priority #18

Why

The runner plugin system (JSON-RPC over stdin/stdout) already exists for custom runners. This issue is about broader extensibility: allowing third-party tools and integrations to attach custom metadata and behavior to steps and pipelines via an x- prefix convention (similar to OpenAPI's x- extensions).

Design Decisions Needed

• Scope — what can x- prefixed fields attach to? Steps? Pipelines? Both?
• Validation — are x- fields passed through unvalidated? Or do plugins register schemas?
• How x- fields interact with runners — passed through as-is? Available via a plugin API?
• Extension discovery — how do consumers of x- fields register themselves?
• Interaction with existing runner plugin system
• Whether x- fields are preserved through FROM inheritance (Implement FROM inheritance (§7) #111)

Spec Reference

• Referenced in spec/core/s21*.md as an exploratory feature

Acceptance Criteria

• Spec section authored
• x- prefixed fields parse without error
• x- fields are preserved in materialized output
• Extension points documented for plugin authors