spec: extract Manifest JSON Schema to schemas/v1/manifest.schema.json + minimal fixture

The manifest contract has lived as prose + an inline schema block inside
spec/04-manifest.md §5 since v1.0. That made every downstream tool
re-implement its own interpretation: the Hub validates server-side, the
CLI bounces all decisions to the Hub, an IDE has nothing to autocomplete
against, CI lint cannot validate a candidate manifest before publish.

This commit lifts the inline schema into a standalone, canonical
JSON Schema 2020-12 file. spec/04-manifest.md now points at the file
as the source of truth for any tooling that needs to validate a
manifest. Inline snippets remain for human readers.

## What landed

  schemas/v1/manifest.schema.json
    641 lines, Draft 2020-12, $id = https://jecp.dev/schemas/v1/manifest.schema.json
    additionalProperties: false at every level (catches typos)
    Per-field descriptions ported from spec prose so the schema is
    self-documenting in IDEs that surface JSON Schema descriptions
    Captures: namespace/capability identity, endpoint, authentication,
    actions (with composes / pricing / input_schema / output_schema /
    sla / side_effects), compliance, billing, deprecation,
    metadata + extensions escape hatch.

  fixtures/manifest-minimal-valid.json
    The smallest object that validates. Smoke-tested with
    Python jsonschema.Draft202012Validator — both schema-validity
    and fixture-validity green.

## What this unblocks

- CLI client-side `jecp provider validate <yaml>` without round-
  tripping to the Hub.
- IDE autocomplete + inline validation in VS Code / JetBrains via
  the standard JSON Schema mechanism (point the editor at the $id URL).
- Conformance YAMLs for /v1/providers/* can reference the schema by
  $id, removing prose-vs-test drift.
- A future @jecpdev/sdk JecpProviderClient can generate TypeScript
  types from the schema instead of hand-rolling them.
- CI lint on jecp-spec itself can verify every example in the
  manifest documentation against the schema.

## What this does NOT do

- No x402 fields (usdc_payout_address, payment_methods). Those are
  in the AUTHORIZED_SETTLER redesign currently in flight. Until the
  redesign lands they live under manifest.extensions{} as
  extension-namespace properties. v1.1 of this schema will promote
  them to first-class fields.

- No spec wording change beyond a pointer line. The prose schema
  description in §5 still reads exactly as before; the new schema
  is normative because it is referenced from §5, not because it
  replaces the prose.

Verified: schema valid against Draft 2020-12 metaschema; fixture
validates; one negative test (invalid namespace) rejects with the
expected pattern violation.

Author: tufedev

fixtures/manifest-minimal-valid.json

@@ -0,0 +1,41 @@
+{
+  "namespace": "example",
+  "display_name": "Example Translator",
+  "capability": "translate",
+  "version": "1.0.0",
+  "description": "Translate text between supported languages.",
+  "endpoint": "https://example.com/jecp",
+  "actions": [
+    {
+      "id": "translate",
+      "name": "Translate text",
+      "description": "Translate input text to the target language.",
+      "pricing": {
+        "base": "$0.005",
+        "currency": "USDC",
+        "model": "per_call"
+      },
+      "input_schema": {
+        "type": "object",
+        "required": ["text", "target_lang"],
+        "properties": {
+          "text":        { "type": "string", "maxLength": 5000 },
+          "target_lang": { "type": "string", "pattern": "^[a-z]{2}$" }
+        }
+      },
+      "output_schema": {
+        "type": "object",
+        "properties": {
+          "translation":   { "type": "string" },
+          "detected_lang": { "type": "string" }
+        }
+      },
+      "examples": [
+        {
+          "input":  { "text": "Hello", "target_lang": "ja" },
+          "output": { "translation": "こんにちは", "detected_lang": "en" }
+        }
+      ]
+    }
+  ]
+}