fix(graphify): default issue-flow build to update, not extract

[jepegit]

graphify extract requires an LLM API key (Gemini / Anthropic / OpenAI
/ Kimi) or --backend ollama. Defaulting to extract meant
issue-flow build failed on every fresh machine with
error: no LLM API key found. Cursor's own LLM is not exposed to
subprocesses, so graphify cannot reuse it — there is no shim that
makes extract work without an explicit backend.

graphify update produces the same graphify-out/ directory
(graph.json, graph.html, GRAPH_REPORT.md) on a fresh repo, runs in
seconds, and prints "no LLM needed" in its own output. Trade-off: the
default graph lacks semantic relationships an LLM pass would surface;
that is the right trade for a default that just works. Power users
opt into the deeper build with issue-flow build extract after
configuring a backend.

Changes:

• _DEFAULT_BUILD_SUBCOMMAND flipped from extract to update in
  src/issue_flow/graphify.py (with rationale in the comment block).
• Docstrings on cli.build and run_build now lead with the no-LLM
  default and document the API-key requirement (and --backend ollama escape hatch) for extract.
• README, build template, build skill, rules entry,
  cursor-issue-workflow doc, and issue-close template all rewritten
  to advertise update as the default. Each now states explicitly
  that Cursor's LLM is not available to subprocesses and points at
  the four supported env vars + Ollama as the upgrade paths.
• Tests flipped to expect update as the injected default; the
  leading-flag test now uses --force (a real update flag) instead
  of the previous --no-cluster (an extract flag).
• Design doc grows a new "Default subcommand is update, not
  extract" section explaining the LLM-key gate and what slipped
  through originally (mocked subprocess never exercised the API-key
  precondition).

Co-authored-by: Cursor cursoragent@cursor.com