Evaluate Graphify as an opt-in code-comprehension aid for modernization/aidlc (brownfield understanding)

## Summary

Evaluate bundling [Graphify](https://graphify.net/) ([safishamsi/graphify](https://github.com/safishamsi/graphify), MIT) as an **optional** code-comprehension aid for the `modernization` and `aidlc` plugins — distinct from the Knowledge Wiki grounding layer (#54).

## Why this is separate from #54

#54 (Knowledge Wiki) is about *pre-generation grounding* over a **narrow curated corpus** (`schemas/ontology/` + ADR/Spec) to prevent ontology drift. That is a correctness-axis layer and should keep a minimal first-party implementation (see the [prior-art evaluation on #54](https://github.com/aws-samples/sample-oh-my-aidlcops/issues/54)).

This issue is the *other* value proposition Graphify surfaced: **understanding an unfamiliar whole codebase**. That is exactly the brownfield problem `modernization` (6R: assess → strategize → containerize → cutover) and `aidlc` construction already face — and where Graphify's whole-repo graph (god nodes, community detection, cross-file/cross-modal "surprise" edges, `rationale_for` edges) is a natural fit rather than an over-scoped one.

## What Graphify offers here

- Multi-modal extraction: code (19 langs via Tree-sitter), Markdown, PDFs, diagrams — useful for legacy repos with mixed docs.
- Whole-repo map: "god nodes" (highest-degree concepts) and surprising cross-module edges to prioritize assessment.
- Reported ~71.5× token reduction vs naive context loading on a mixed corpus — relevant for large legacy estates.
- Ships as a slash command + optional MCP server; AST pass is local (no code leaves the machine), only semantic descriptions hit the configured model.

## Open questions to resolve before adoption

1. **Opt-in only.** Must be a non-default, clearly-flagged optional skill — not wired into the core install path. OMA's "install a plugin → dual-axis" promise should not depend on a third-party graph builder.
2. **Maturity / sustainability.** Released 2026-04-03, single maintainer. Acceptable for an *optional* aid; would need a vendoring/pinning story before any deeper reliance.
3. **Config-ownership overlap.** Graphify installs its own PreToolUse hook + CLAUDE.md directives; OMA's harness owns a PreToolUse hook. PreToolUse arrays are additive, but the composition must be tested (both hooks fire, neither suppresses the other).
4. **Dependency weight.** NetworkX + Tree-sitter + optional vision models — confirm this is acceptable to bundle or whether it stays a documented external install.

## Acceptance criteria (draft)

- [ ] Decision recorded (adopt as optional skill / document-only / decline) with rationale
- [ ] If adopted: lands as an opt-in skill in `modernization` (and/or `aidlc`), not the default path
- [ ] PreToolUse hook composition with the OMA harness verified (both fire; no suppression)
- [ ] Dependency + sustainability story documented (pin/vendor or external-install)

## References

- [graphify.net](https://graphify.net/) · [safishamsi/graphify](https://github.com/safishamsi/graphify) (MIT)
- #54 — Knowledge Wiki grounding layer (the *correctness-axis* use; this issue is the *comprehension* use)

_Filed from the plugin-UX re-verification thread. OMA currently has zero in-repo references to Graphify._

Start by inspecting the modernization and aidlc plugin entry points and the OMA harness's PreToolUse configuration. Compare those integration points with Graphify's optional skill, hook, and dependency model. Done means recording an adopt, document-only, or decline decision with rationale and addressing the listed opt-in, hook-composition, dependency, and sustainability criteria.

Written by the indexing model from the issue text.