Spec tier above vetted in tier resolution + gate validates problem_spec against the entitlement-keyed schema variant

[aarontrowbridge]

Roadmap context: vault plan `plan-20260812-142100-problemspecs-issimo-roadmap` (W2.2 + W2.4); master spec §"Tier semantics".

Tasks

• Spec tier: `packages/amico-run/src/catalog.ts` — `spec` becomes the top tier above `vetted`: fully validated data, no authored code. A spec-expressible formulation resolves to `spec` without consulting `templates/registry.toml`; out-of-subset falls through to vetted/composed/free with the reason surfaced. Update the score's solve-stage language + entitlements.toml accordingly (open question 1 in the master spec: "spec" vs folding into "vetted" with a kind field — this issue resolves it as a distinct tier).
• Gate-side problemspec validation: today a `problem_spec` payload is only shape-checked (`{type: object}`) by the solvespec schema. Run `validate(problemSpec, "problemspec")` in `gate.ts` so malformed specs bounce before paying a Julia cold start.
• Entitlement-keyed variant: choose the vendored FULL vs OSS schema by the user's package access (`issimo` entitlement ⇒ full, else OSS) — makes `problemspec.oss.schema.json` load-bearing for the first time and enforces the public/private seam at the gate, matching the Julia-side "capability = what's loaded" rule.

Acceptance

• A spec naming a Piccolissimo-only integrator (`exponential`/`spline`) fails the gate with a structured entitlement error on an OSS-entitled install, and passes on an `issimo` one.
• Tier resolution unit tests: spec-expressible ⇒ `spec`; custom objective ⇒ `free` fallback with reason; vetted shapes still resolve `vetted` when the script path is explicitly requested.

[jeonghun-jj-lee]

Closing — the spec-tier system (vetted/composed/free) is live in the product. Tier resolution and entitlement-keyed validation are wired.