feat(APP-795): Integrate Aragon subdomain and implement Aragon profile renaming

[milosh86]

Description

• Propose a minimal approach for aragon-subdomain integration (see the section below)
• Implement Aragon name changing

Integration approach:

• We use the same "Service" abstraction as we already use in the App for interacting with backend and RPC
• Each service method has its own API route
  • This is different to the existing backend and RPC based services which have single API route acting as a proxy!
  • We need to implement common operations like response parsing, error handling and monitoring in a reusable way
• We have shared AragonSubdomainServiceClient used in HTTP client path (extended by specific client services)
• We have AragonSubdomainServiceServer used in the API routes and in the service server path
• Specific service implementation, e.g. memberProfileService
  • Service has a client and a server part
  • Domain interfaces should come straight from the aragon-subdomain, instead of re-implementing the same interfaces
  • api.ts file implements all "params" interfaces
  • Even though server path uses domain controller which is not HTTP interface, we should probably keep param interfaces in the same format in all cases... to be confirmed
  • Client part of the service is identical to the existing backend services, except it extends AragonSubdomainServiceClient
  • Server part of the service has identical interface as the client part, but internally, it uses shared aragonSubdomainServiceBackend, which is basically instantiated AragonDomainController
• Tanstack queries
  • Queries have identical structure to existing backend queries, except they are only intended for the client side!
  • For the server component calls, using queryClient.fetchQuery(queryOptions()), we have .server.ts query file which exports only a function for generating server component query options. It reuses client function completely plus it adds new queryFn
  • For the sake of caching, it is important to use the same query key in both client and server case!

Type of Change

• Minor: Feature (non-breaking change which adds new functionality)

Developer Checklist:

• Manually smoke tested the functionality in a preview or locally
• Confirmed there are no new warnings or errors in the browser console
• Confirmed there are no new warnings on automated tests
• Selected the correct base branch
• Commented the code in hard-to-understand areas
• Followed the code style guidelines of this project
• Reviewed that the Files Changed in Github's UI reflect my intended changes

[linear-code]

APP-795

[github-actions]

🚀 Preview Deployment: View Here

[github-actions]

E2E results (preview)

Smoke

Base URL	https://app-next-cm6nrj81h-aragon-app.vercel.app
Suite	smoke
Playwright result	✅ passed
Summary	79 passed, 1 skipped
HTML report	View report
GitHub job	✅ completed

View run #4335

[thekidnamedkd]

Think we've got a data-loss issue here 👀 — contenthash: '0x' wipes any existing contenthash, and addr is the connected wallet rather than the name's current addr record. On top of that getEnsTextRecords only pulls text records, so addr/contenthash never get read from the profile at all.

Since the AC is "move all records", we should fetch the full Records (text + addr + contenthash) for the current name and pass them through unchanged. Worth testing against a profile that actually has a contenthash set so we don't silently nuke it on rename.

[thekidnamedkd]

One more edge case here: the SDK returns [] both when a profile genuinely has no text records and when the name/resolver isn’t found. That means indexer lag or a lookup miss would still enable submit and we could pass an empty textRecords array into move.

Could we make the records response distinguish “found with zero records” from “not found”, and only enable the rename once we know we loaded the current profile successfully?

[thekidnamedkd]

This throws at import time, before the route's try/catch can catch it — so a missing endpoint surfaces as an opaque import crash instead of a clean 500. Fine if we trust deploy config, but can we double-check both new secrets are set in every preview/prod env where the profile dialog renders?

Also apiToken has no null check before it goes into EnvioClient — intentional (token's optional) or a miss?

[thekidnamedkd]

The new service + both dialogs land without any tests — we should add a couple. Most valuable would be one asserting the encoded move args (that'd catch the records issue above), plus the button-hidden-for-personal-ENS case. userDialog.test.tsx is a good template.

[thekidnamedkd]

move is overloaded in the ABI now (move(string) + move(string, Records)) — viem picks the right one by arg count so this works, just flagging the single-arg version has no callers left. Intentional to keep it around?

[thekidnamedkd]

Looks like a copy-paste from the RPC routes — this one's Envio GraphQL, not RPC.

Suggested change

	* Parameters of the RPC request call.
	* Parameters of the request call.

[thekidnamedkd]

This key skips apiVersionUtils.getApiVersion() that our other service keys include — fine if this endpoint is intentionally version-stable, otherwise we should align it so cache busts on version bumps.