Source customization type_names.prefix is not applied to *_aggregate_bool_exp types

### Version Information

Server Version: v2.50.0 (also present in v2.50.1 changelog — no related fix)
CLI Version (for CLI related issue): n/a (metadata applied via API)

### Environment

OSS (Community Edition), self-hosted via Docker.

### What is the current behaviour?

When a source is configured with `customization.type_names.prefix`, the prefix is applied to most generated GraphQL types, but **not** to the aggregation-predicate family:

- `_aggregate_bool_exp`
- `_aggregate_bool_exp_bool_and`
- `_aggregate_bool_exp_bool_or`
- `_aggregate_bool_exp_count`

These four are emitted with the bare table name. What makes it look like an oversight rather than a design decision: the **fields inside those very types are prefixed correctly**.

From the introspected schema of an instance whose source uses `type_names.prefix: bluefable_` (the type name is bare, its fields are not):

```graphql
input booking_aggregate_bool_exp {
bool_and: booking_aggregate_bool_exp_bool_and
bool_or: booking_aggregate_bool_exp_bool_or
count: booking_aggregate_bool_exp_count
}

input booking_aggregate_bool_exp_bool_and {
arguments: bluefable_booking_select_column_booking_aggregate_bool_exp_bool_and_arguments_columns!
distinct: Boolean
filter: bluefable_booking_bool_exp
predicate: Boolean_comparison_exp!
}
```

Everything else for the same table is prefixed as configured: `bluefable_booking_bool_exp`, `bluefable_booking_select_column`, `bluefable_booking_set_input`, and so on.

### What is the expected behaviour?

`*_aggregate_bool_exp` and its `_bool_and` / `_bool_or` / `_count` companions should follow the same source customization as every other generated type, i.e. `bluefable_booking_aggregate_bool_exp`.

The practical consequence of them not doing so: **two sources in one instance cannot both have a table with the same name and an array relationship to it**, even though both sources are fully customized with distinct namespaces and distinct type prefixes. Adding such a relationship fails schema building with:

```
Found conflicting definitions for GraphQL type ...
```

Per-source prefixes exist precisely to make same-named tables across sources safe, so this is a real hole in that guarantee: relationships, not just naming, become unavailable.

### How to reproduce the issue?

1. Add two Postgres sources, `A` and `B`, each with customization — distinct `root_fields.namespace` and distinct `type_names.prefix` (e.g. `a_` and `b_`).
2. Create a table named `booking` in both sources, plus a parent table in each (e.g. `guest`), and track them all.
3. In source `A`, add an **array relationship** `guest.bookings -> booking`. Schema builds fine, `booking_aggregate_bool_exp` appears in the schema — unprefixed.
4. In source `B`, add the same array relationship `guest.bookings -> booking`. Metadata application fails with `Found conflicting definitions for GraphQL type`, because `booking_aggregate_bool_exp` is already taken by source `A`.

Note that steps 1–2 alone are fine: the conflict only appears once an array relationship makes Hasura generate the aggregation-predicate types.

### Screenshots or Screencast

n/a — the introspection excerpt above shows it directly.

### Please provide any traces or logs that could help here.

The error surfaces on metadata application / schema build as `Found conflicting definitions for GraphQL type "_aggregate_bool_exp"`. In our case the instance hosts seven unrelated sources, each with its own namespace and prefix; two of them have a `booking` table, and the second array relationship to it is what triggers the failure.

### Any possible solutions/workarounds you're aware of?

1. `HASURA_GRAPHQL_EXPERIMENTAL_FEATURES=hide_aggregation_predicates` — works (the conflicting types are no longer generated), but it is **instance-wide**: aggregation predicates disappear for every source, including unrelated projects sharing the instance. Not viable for us.
2. Renaming the table via `custom_name` in the source's table configuration, restoring the previous API surface with `custom_root_fields`. This is the shape of a workaround we're considering, since type names are derived from the (custom) table name — but it changes the names of *all* types for that table, which leaks into every document that references an input type.
3. Not using array relationships to the conflicting table at all (computing aggregates through a view instead). This is what we do today; it avoids the conflict rather than solving it.

A proper fix would simply route these four type names through the same customization path as the rest.

### Keywords

aggregate_bool_exp, type_names prefix, source customization, Found conflicting definitions, aggregation predicates, array relationship, multiple sources same table name

Start at metadata application and schema-build handling for source customization.type_names.prefix, then trace generation of the four aggregation-predicate types: *_aggregate_bool_exp, *_bool_and, *_bool_or, and *_count. Reproduce with two Postgres sources containing same-named tables and array relationships; done means every aggregation-predicate type receives its source prefix and schema building succeeds without conflicting definitions.

Written by the indexing model from the issue text.