[P2-34] Generate versioned, release-scoped Graphify architecture output

[phranck]

Problem

The repository currently contains no graphify-out/graph.json, Graphify configuration, or versioned architecture graph history. Graph-based architecture queries are therefore unavailable or necessarily stale, despite the project size and multi-target dependency structure.

Generating graphs on every normal push would add churn and conflicts, so freshness needs an explicit release-scoped policy.

Proposed solution

• Define a pinned Graphify version/configuration for Swift targets, tests, examples, and project-template content.
• Generate a versioned graph with source paths/symbol relationships and documented exclusions.
• Add validation that a version/release update refreshes the graph, while ordinary pushes do not rewrite it.
• Document how agents and maintainers query and verify the graph.
• Keep graph output deterministic and free of local absolute paths or secrets.

Acceptance criteria

• A clean checkout can reproduce the same graph with the pinned tool/configuration.
• All package modules and intended cross-target relationships appear; generated/build/vendor artifacts are excluded.
• Release/version workflows detect missing or stale graph output.
• Normal nonrelease pushes do not regenerate Graphify.
• The graph contains no machine-specific paths, credentials, or unrelated private data.
• Graph generation and repository quality gates are warning-free.

Dependencies

Independent of runtime implementation. Final graph should be regenerated after public module/API restructuring.

Parallelization

Configuration and deterministic-generation preparation can start early, but this issue is neither Ready nor complete until the final release snapshot is generated after #35 and the API migration.

Commit structure

• Split this issue into small, thematic, independently revertible commits wherever the work can remain coherent.
• Every commit must build and keep its applicable tests/gates green. Do not commit an intentionally failing regression test; use local/known-issue characterization or land the test with the smallest fix.
• Keep characterization/fixtures, mechanical renames or moves, semantic changes, and documentation/migration updates separate when each step remains green.
• The issue boundary is not a commit boundary; multiple commits are expected for independently reversible changes.