[skill] --wiki flag has no implementation step: running after Step 9 cleanup silently loses community labels #229

Problem

The --wiki flag is documented in the usage section but Step 6 of the skill only handles
--obsidian and HTML. There is no wiki generation step.

This creates two related failure modes:

1. Pipeline ordering bug: Anyone who uses --wiki does so outside the documented flow —
   typically after Step 9, at which point .graphify_labels.json has already been deleted.
   to_wiki() receives None for community_labels and silently falls back to
   [[Community 0]], [[Community 1]], etc., discarding the labels set in Step 5.

2. Post-pipeline wiki regeneration is impossible: Even if a user ran the full pipeline
   correctly (without --wiki), they cannot regenerate the wiki later with correct labels.
   Community labels are ephemeral — deleted in Step 9 — and not persisted anywhere.
   graph.json stores integer community IDs per node but not the human-readable names.

Expected behavior

Wiki generation should run in Step 6 (before Step 9 cleanup), with access to
.graphify_labels.json. The --wiki flag should remain opt-in, consistent with
--obsidian, --svg, and other optional outputs.

Two solution paths

Path A — Fix the skill only:
Add a wiki generation block to Step 6, between the HTML block and Step 7, that reads
.graphify_labels.json before Step 9 deletes it. Simple, minimal change.

Path B — Fix the root cause:
Persist community labels to graphify-out/labels.json as a first-class output artifact
in Step 5 (alongside graph.json and GRAPH_REPORT.md). This also enables:

• Post-pipeline wiki regeneration at any time
• --update and --cluster-only reruns that can reuse existing labels without
  re-running the full labeling step

Note: this is separate from #228 (wikilink format issue in wiki.py) which concerns
the library output format. This issue is about the skill's pipeline ordering and label
persistence.