ESS skills: init ignores an existing specification, the refusal recorder is Go only, init plans without --host #32

Checked against main at 2f82cbc, plugin 0.14.11, ess 0.32.1.

1. ess:init does not start from a specification that already exists

plugins/ess/skills/init/SKILL.md step 2 is a routing table: new specification, retrofit, or conformance. In a repository that already has ess-inputs.yaml, a passing conformance suite and a task runner that wraps both, the skill offers the same three choices and reads nothing. The standing of that repository took two commands to establish: ess specify validate (valid) and the repository's own conformance task (121 scenarios, 0 failed).

Expected: when system.yaml or ess-inputs.yaml is present, step 2 first runs ess specify validate --path <dir> and the repository's conformance command (from its AGENTS.md or task runner), reports the counts, and recommends ess:testing-conformance when the suite is green, because a green suite nobody has broken is the next question.

2. ess:testing-conformance: the refusal recorder is shown in Go only

The "Ranking the skips" section's recorder example (line 58) is Go: errors.Is(err, essconform.ErrUnsupported). The same skill documents --target typescript. The TypeScript runner reads a refusal from new Error("...", { cause: ErrUnsupported }), per the generated package's README.md, and nothing in the skill shows that form.

Expected: a TypeScript twin of the recorder, wrapped around executeCommand, queryView and the entity setup, appending subject\treason when err.cause === ErrUnsupported and CONFORMANCE_REFUSALS is set.

3. ess:init plans without --host

Line 17 prints b10x init ess --out ~/.local/state/b10x/plan.json, while b10x:init step 4 says to plan for the host you run in (--host claude / --host codex). Following ess:init in Codex plans for the default host.

Expected: the same --host wording as b10x:init, in every product's init skill.