feat(kyberforge): execute plugin-to-apm marketplace conversion

Why:
ADR-0015 established that Microsoft APM (apm.yml + .apm/) should replace
this repo's hand-authored plugin.json/marketplace.json model, with those
files becoming compiled output of `apm pack` instead of files edited by
hand via the (now-retired) plugin-author/marketplace-author skills.
Issue #90 was the deferred execution of that decision, gated on #88
(apm tooling) and #89 (apm-native agent-author/skill-author routing).

Implementation notes:
- All six plugins (bin, core, git, gitea, kyberforge, lint) now carry
  apm.yml + .apm/{skills,agents,hooks} as their authoring source. Skills
  moved with a plain git mv (content-identical across targets). Agents
  were re-authored, not moved: per ADR-0016, .apm/agents/*.agent.md
  compiles verbatim to both Claude and Copilot, so plugin-scope agents
  now carry only name/description/model/source_keys -- no tools: field,
  no Claude-only knobs (isolation, maxTurns, effort, memory,
  permissionMode).
- Root apm.yml registers all 7 marketplace packages (6 local plus
  mattpocock-skills as a remote entry) under versioning: per_package,
  matching this repo's existing independent-plugin-versioning practice.
- .claude-plugin/marketplace.json and every plugin's plugin.json are now
  apm-pack-compiled output, verified against the prior hand-maintained
  content: same names/descriptions/versions/licenses/authors, only
  cosmetic serialization differences (JSON key order, owner email vs.
  url, Unicode escaping).
- plugin-author and marketplace-author are retired now that apm-based
  authoring fully replaces their job; kyberforge bumped 1.3.1 -> 1.4.0
  for that removal, and the root marketplace catalog bumped
  0.3.1 -> 0.3.2 to match, per the version-bump convention now
  documented in apm-workflow's reference docs instead of a dedicated
  script (apm has no native version-bump automation).
- Fixed hardcoded pre-.apm/ path assumptions across
  .pre-commit-config.yaml, .pre-commit-hooks.yaml,
  scripts/check-scope-walkup-sync.sh, scripts/sync-vale-styles.sh,
  scripts/check-vale-style-sync.sh, six plugins' root plugin.json
  (stale skills/hooks/agents pointer fields that check-manifests.sh
  validates), and several tests/*.bats and tests/*.sh fixtures --
  including a bats REPO_ROOT relative-path depth bug (10 files, one
  extra .apm/ directory level to walk up) and a vale probe-path
  isolation regression introduced mid-fix.
- Corrected empirically-wrong assumptions surfaced this session in
  apm-workflow/apm-install's own reference docs: `apm marketplace
  package add` does not accept local paths (only owner/repo remote
  shorthand -- local packages are registered by editing apm.yml's
  marketplace.packages[] directly); `apm compile` is a consumer-side
  AGENTS.md/CLAUDE.md generator, not the plugin.json producer, and
  hard-fails on skill/agent-only packages without --clean; `apm plugin
  init <name>` nests a stray subdirectory when run with a positional
  name arg from inside a same-named directory; no native Copilot
  marketplace output profile exists; .mcp.json is merged into the
  compiled plugin.json content-aware and target-scoped, with no
  dependencies.mcp entry needed for simple passthrough; pipx is the
  correct pip fallback on externally-managed Python environments.
- Renamed agent-author's copilot.agent.md template asset to
  copilot.agent.md.template so apm compile's recursive *.agent.md glob
  stops misparsing the placeholder template as a real agent primitive.

Impact:
plugin.json and marketplace.json are compiled artifacts from here on --
editing them by hand is no longer the workflow; edit apm.yml/.apm/ and
run apm pack. CONTEXT.md's Plugin/Plugin marketplace glossary entries
reflect this. ADR-0001 is marked superseded, ADR-0006 moot, and
ADR-0010 updated for the new .apm/agents/ path (project/user scope
unaffected, per ADR-0016). Full local verification: claude plugin
validate --strict on all 6 plugins, apm audit --ci, apm marketplace
check, check-manifests.sh, and the full test suite (165/165 bats,
13/13 shell scripts) all pass clean.

Fixes: #90
Refs: #88, #89
ADR: 0015
ADR: 0016

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ub96PyaSRD9BHPktotj1pC

plugins/gitea/skills/gitea-labels-milestones/references/label-inference.md

@@ -1,68 +0,0 @@
----
-topic: label-inference
-source_keys:
-  - context7-websites-gitea
-  - gitea-mcp-repo
----
-
-# Label inference guide
-
-Maps context-pattern signals from conversation content (an issue being drafted, a bug report, a PR
-description) to this repo's `Kind/*` / `Priority/*` / `Status/*` label taxonomy. Used by
-`gitea-issues` and `gitea-prs` before creating or updating an issue/PR, and directly when the user
-asks to label something without naming exact labels.
-
-## Scoped labels are mutually exclusive — replace, don't stack
-
-Each of `Kind/*`, `Priority/*`, `Status/*` is treated as a scoped-label group by convention (the `/`
-delimiter naming pattern). Gitea's `exclusive` flag — the mechanism that would let the server itself
-enforce one-label-per-scope — is documented as an org-labels-only setting, and the repo-level
-`label_write` methods used here don't accept it at all. So exclusivity within these scopes is a
-convention this skill enforces client-side, not something the server guarantees: applying a new
-label within a scope is expected to replace any existing label in that same scope on the target
-issue/PR, not add alongside it. When inference
-selects a `Priority/High` label and the issue already carries `Priority/Medium`, the write should
-result in only `Priority/High` remaining — use `replace_labels` scoped to that group's labels, or at
-minimum remove the superseded label before adding the new one. Never leave two labels from the same
-scope applied at once.
-
-## Signal → label mapping
-
-**`Kind/*`** (what kind of work this is):
-
-| Signal in context | Label |
-|---|---|
-| Bug report, error, crash, unexpected behavior, "broken", "doesn't work" | `Kind/Bug` |
-| New capability, "add support for", net-new functionality | `Kind/Feature` |
-| Improvement to existing behavior, "make X better", refactor with behavior change | `Kind/Enhancement` |
-| Docs-only change, README/comment/guide updates | `Kind/Documentation` |
-| Vulnerability, credential exposure, injection risk, auth bypass | `Kind/Security` |
-
-**`Priority/*`** (urgency):
-
-| Signal in context | Label |
-|---|---|
-| "blocking", "critical", "urgent", production-down | `Priority/Critical` |
-| "soon", "high priority", "should do this sprint" | `Priority/High` |
-| No urgency signal present | `Priority/Medium` (default) |
-
-**`Status/*`** (workflow state):
-
-| Signal in context | Label |
-|---|---|
-| Explicit statement that the work is blocked on something else | `Status/Blocked` |
-
-## Procedure
-
-1. Read the conversation context (issue/PR title, body, or the triggering discussion) for the
-   signals above.
-2. Call `label_read method: "list_repo_labels"` (see `references/labels.md`) to get the current
-   label set with IDs — inference must never guess an ID, only a name, then resolve it.
-3. Match inferred label names against the resolved list (case-insensitive). If a scope group
-   already has a different label applied on the target and a new one is inferred for that same
-   scope, plan to replace rather than add (see above).
-4. **Low-confidence inference omits the label.** If no signal confidently maps to a `Kind/*` value,
-   do not guess — omit `Kind/*` entirely rather than default to one. `Priority/Medium` is the one
-   exception: it's the explicit default when no urgency signal is present, not a guess.
-5. Hand the resolved IDs (plus which scopes to replace) to the caller's `issue_write`/
-   `pull_request_write` call — this skill does not apply labels to an issue or PR itself.