Inconsistency between "Dynamic" routing and "static" graphQL types

### Is your proposal related to a problem?

Hasura has a clear segregation of database routing using request headers / JWT claims to route to the right destined DB. However, if the schema for the databases remain the same all across, we are forced to use the `custom_name` for tables or to have different namespaces. The downside to this approach is, the clients (could be UI or other services) have a well bound statically type-checked GraphQL schema, that makes it easy to access their data via Hasura GraphQL engine. However, when we introduce these `custom_name`s for each of the tables, we lose the ability for static typing and Hasura expects us to have Dynamic Types here.
This is clearly not an easy way out with say a multi-tenant distinct database approach.

The effects of this problem are:
1. Say, I have two different databases (same DB schema for both) and we are using Dynamic routing to query the right database
2. In order for Hasura to "Track" and make them available for GraphQL queries, we are forced to have a custom_name for each type
3. Now, if we proceed with this idea, we are forced to regenerate the client graphQL schema everytime there are additions and new custom types.
4. This also makes the client to be "tenant-aware" / "dynamic-schema aware", which contradicts with the "dynamic-routing" in principle.

### Describe the solution you'd like

If the dynamic routing is defined, it makes sense for Hasura to auto-namespace within and not force the external service to be aware of the custom types.

Review Hasura's dynamic database routing and GraphQL type-tracking behavior described in the issue, focusing on how custom_name values are required across identically shaped databases. Define a design that namespaces tracked types internally without exposing tenant-specific names, then validate that clients can retain a static GraphQL schema; no files or tests are identified in the issue.

Written by the indexing model from the issue text.