refactor(kyberforge): retrofit forge to the ADR-0020 contract

Description 648 -> 387 chars, body 1093 -> 541 words. This was the last
body FAIL in the 39-skill corpus.

The body was not trimmed to fit. forge routes four artifact types that a
single invocation classifies between, so the contract requires a dispatch
table plus the gates common to every route, with each route self-contained
in references/. Adds references/author-routes.md (skill and agent),
references/apm-routes.md (plugin and marketplace entry) and
references/version-bump.md. Skill and agent share one file: they differ on
one axis only, which audit skill verifies the result.

Fixes three defects the first pass introduced or relocated:

- references/apm-routes.md claimed `apm audit` "already runs inside
  apm-workflow's own flow" and told the agent to confirm it ran clean.
  apm-workflow dispatches audit as its own row; the configure and
  marketplace rows never reach it. That was the only completion check
  these routes had, and it could never be satisfied. Replaced with a
  manual read-back the agent performs itself.
- "Read only the reference file" forbade the multi-artifact case the same
  body documents two lines later, and ADR-0011 records eight artifacts
  authored in one pass.
- The announce gate became a closing gate, reachable only after the
  invocation it was meant to precede. Moved to the end of Step 2.

Also restores the artifact enumeration to the plugin row, normalises to
bare unnamespaced skill names per AGENTS.md, adds a dispatch fallback for
artifacts matching no row, and corrects three provenance entries -- one
asserted a contribution that did not happen.

Refs #99

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MWb5RQgCL1ye7cGp2RPb2u

plugins/kyberforge/skills/forge/references/version-bump.md

@@ -0,0 +1,37 @@
+---
+source_keys:
+  - claude-code-subagents-docs
+---
+
+# Bumping the package version after a route
+
+Reached from `SKILL.md` Step 3 when a route has finished and its completion message carries no
+evidence that the package version was bumped. The author skills bump it themselves in some flows,
+so check their output before doing anything here — a second bump for one artifact is wrong.
+
+## Find the owning package
+
+Walk up from the artifact's path to the nearest ancestor `apm.yml` that declares a top-level
+`type:` field (`instructions`, `skill`, `hybrid` or `prompts`).
+
+An `apm.yml` with **no** `type:` field is a marketplace-only manifest: it lists packages rather
+than declaring one, so it does not count as a match. Skip it and keep walking up.
+
+Skip this step entirely if no ancestor `apm.yml` carries a `type:` field: the artifact is then
+standalone or scoped to a user agent directory, and there is no package to version.
+
+## Delegate the bump
+
+Invoke `apm-workflow` as a **clean-context subagent** — fresh, not forked — with this
+brief:
+
+> "The package at `<package-path>` gained a new `<artifact-type>` (`<artifact-name>`). Bump the
+> `version` field in that package's `apm.yml`. Determine whether to bump minor (0.1.0) or patch
+> (0.0.1) based on whether this is a new capability (minor) or a fix/refactor (patch). Do not
+> release or tag — just update `apm.yml` and commit."
+
+Clean context rather than a fork is the point: the bump decision is made independently, without
+anchoring on the authoring conversation that just argued for the artifact's significance.
+
+Then report to the user: "Updated `<package-name>` version from X.Y.Z to X.Y.Z to reflect the new
+`<artifact-name>`."