docs: add OpenSpec baseline for every capability

What does this MR do and why?

Moves the gem to spec-driven development with OpenSpec. This first MR records the gem's current behaviour as an as-built baseline, so later changes can be proposed as deltas against it.

• openspec/specs/: one spec per capability (13 in all), covering compatibility, configuration, cross-field validation, document structure, entity schemas, operations, parameter constraints, parameters, paths, request bodies, responses, tags and type mapping.
• Each requirement carries **Status**:, **Fixtures**: and **Tests**: lines. A requirement whose current output differs from the intended one is marked deviation (#N), with an open issue and a **Current**: line.
• openspec/config.yaml: the project context and the rules for writing specs, proposals, designs and tasks.
• .claude/commands/opsx/ and .claude/skills/openspec-*: the /opsx:* workflow commands.
• README.md, CLAUDE.md and AGENTS.md: document the workflow. The isolation rule now also lists js_regex as a runtime dependency.

There is no code change, so the generated output is unchanged.

How to verify

npx -y @fission-ai/openspec@1.13.2 list --specs
npx -y @fission-ai/openspec@1.13.2 validate --all --strict

Known gaps

Some **Tests**: lines name a spec file that doesn't assert every scenario of its requirement. For example, configuration_spec.rb had no example for the option list, the defaults or the every-option-at-once scenario. Those examples are added later in this stack.

Stack

1. !68 (merged): OpenSpec baseline (docs/openspec-baseline → main) (this MR)
2. !69 (merged): Specification for #32 (32-specify-parameter-annotations → docs/openspec-baseline)
3. !70: Implementation for #32 (32-support-parameter-annotations → 32-specify-parameter-annotations)

Merge from the bottom up: !68 (merged), then !69 (merged), then !70.

🤖 Generated with Claude Code