Mark workflow-centric skills as non-user-invocable for skill-surface clarity

[brenpike]

What

Mark the workflow-centric skills as non-user-invocable, so the skill surface a user sees is only the
skills a user is meant to run.

Why

The workflow engine skills — route-workflow, init-run-ledger, record-state-result, next-wave,
mark-intent-fallback, molt, create-working-branch, open-plan-pr, push-branch — are internal
machinery invoked by the orchestrator as workflow states or navigator calls. A user invoking one
directly gets an engine op with no run context around it: a ledger write with no run, a routing YAML
nobody consumes, a checkpoint outside a plan.

They are currently indistinguishable, in the user-facing skill list, from skills a user genuinely
drives (zoom-out, plan-interrogation, brood-status, seed-hive, improving-architecture).

This is a clarity/ergonomics change, not a safety fix.

Scope questions to settle first

• Does the frontmatter surface support this direction at all? The only invocation flag in use is
  disable-model-invocation: true (used once, on zoom-out), which blocks the model and leaves
  user-only. That is the opposite of what is wanted here. Establish whether a model-only / hide-from-user
  equivalent exists before designing around one.
• Which skills are genuinely engine-internal vs. legitimately user-runnable. brood-status is
  explicitly user-invoked and read-only; molt and push-branch are arguably useful by hand.
• Whether hiding them affects the hivemind:<skill> namespaced references in agent and governance
  bodies (they must keep resolving).

Explicitly NOT this issue

This does not fix, and must not be conflated with, the turn-termination class in #325 / #327.
An invocation flag does not change the bytes a skill body injects into its caller's context, so it
cannot fix or prevent a skill stalling its caller's turn. #327 defect 6 already established that
invocation-source is the wrong axis for that problem. Keep the two apart.