Narrative Overhaul: Rename ENSv2 Plugin to Unigraph

[shrugs]

Edit: Per latest discussion in this Slack thread, idea is that we might rename the ensv2 plugin to namegraph: https://namehash.slack.com/archives/C086Z6FNBHN/p1778598632189739?thread_ts=1778578478.753409&cid=C086Z6FNBHN

• pending confirmation on 'omnigraph' naming
• rename the ensv2 plugin to omnigraph
• update all usage across the project
• ensure that the ENSv2Root datasource remains as-is
• any usage of graphql-api should be omnigraph (prerequisites, some libs)
• endpoint to /api/omnigraph
• ENSNODE_GRAPHQL_API_URL becomes ENSNODE_OMNIGRAPH_API_URL
• apps/ensapi/src/handlers/api/graphql/ensnode-graphql-api.ts becomes apps/ensapi/src/handlers/api/omnigraph/omnigraph-api.ts (maybe omnigraph.handlers.ts)
• also applies to ensadmin's api/graphql becoming /api/omnigraph
• etc etc

[coderabbitai]

🔗 Related PRs

#1566 - feat: separate ensv2 datasources out more correctly [merged]
#1575 - fix: add correct ensv1 and ensv2 addresses to sepolia-v2 namespace [merged]
#1730 - Remove Core Plugin Restriction [merged]
#1758 - fix: allow ensv2 apis to be used without ensv2 datasource [merged]
#1855 - feat(ensapi): add tracing support with Pothos plugins and enhance GraphQL execution tracing [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[lightwalker-eth]

@shrugs I'm thinking it's nice to keep the plugin named as ensv2. This aligns with the idea of the separation of concerns between ENSIndexer -> ENSDb -> ENSApi and more broadly between ENSDb Writers -> ENSDb -> ENSDb Readers.

There should be a decoupling of ideas. The Omnigraph API is the ultimate reference implementation of an ENSDb Reader, but other ENSDb Reader services may be created building all kinds of other APIs off of an ENSDb instance. When these other ENSDb Reader services go to check which plugins were activated, I think it's better they see "ensv2" than "omnigraph".

The idea of the Omnigraph lives only in the ENSDb Reader layer as implemented in ENSApi.

[lightwalker-eth]

We'll keep the ENSv2 plugin named as ensv2 👍