Bare mex graph always does a full build, even when the graph is already fresh

[theyashasvipandey]

mex graph with no subcommand runs an unconditional full rebuild —
runGraph in src/graph/cli-graph.ts:54 calls rebuildGraph() directly.
Running it twice on an unchanged repository rebuilds everything both times.

Measured on honojs/hono @ 4.12.32 (381 indexed files, 13,240 nodes):

command	wall clock	files indexed
mex graph (cold, no graph)	65 s	381
mex graph (immediately again, nothing changed)	367 s	381
mex graph refresh (nothing changed)	14 s	0

graph status reported fresh throughout the second and third runs.

The 367 s figure is a single observation on a machine that was not isolated, and
the variance in #140 is unexplained — please read it as "another full build",
not as a calibrated number. The reproducible part is the file count: 381 files
re-indexed against a store that status had just called fresh.

Why this is worth changing

refresh already does the freshness check, and on a fresh store it costs 14 s
instead of a full build. The cheap path exists; bare mex graph just does not
route to it.

Suggested behaviour

1. Check freshness, as status already does.
2. Already fresh → report and exit without writing.
3. Compatible graph with changes → what refresh does.
4. Missing, incompatible or unusable store → full build, as today.
5. Keep an explicit escape hatch (--force, or point at rebuild).

Two corrections to how this was first reported

• The help text no longer reads Build the code knowledge graph into .mex/graph.db.
  On main it is Inspect or explicitly maintain the code knowledge graph, so
  the command no longer claims to build. It still does.
• This is a deliberate design decision, not an oversight —
  docs/design/graph-freshness-recovery.md:16 states "Bare mex graph is a
  compatibility alias." So this is a request to revisit that decision, and the
  maintainers may reasonably prefer to keep the alias and redirect users instead.

Before changing it

Several call sites hand mex graph to users as a guaranteed-build recovery
command and would need auditing or repointing at rebuild:

• src/graph/errors.ts:19 — recoveryCommand = "mex graph", and the message
  "Run mex graph to rebuild it."
• src/graph/db/database.ts:79 and :189
• src/graph/cli-agent.ts:2030 — GRAPH_UNAVAILABLE remediation
• the Hub's { label: "Build graph", command: "mex graph" } remediation

Most of these fire when the graph is missing or unusable, where step 4 already
does a full build — but they should be checked rather than assumed.