[1.x Bug] Batch metadata source freshness returns another project's table metadata when two sources share a schema/dataset name

### Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

- [ ] I believe this is a new bug in dbt-core
- [x] I have searched the existing issues and could not find a duplicate

### Current Behavior

_Note: I originally opened a ticket in the bigquery adapter repo (https://github.com/dbt-labs/dbt-adapters/issues/2107), but not actually sure if that's the right place for it, so reposting here... promise I'm not just deliberately spamin' for attention 😅_

With `bigquery_use_batch_source_freshness` enabled, dbt source freshness can report the
freshness of a completely different physical table, in a different BigQuery project, for a
source. The reported `max_loaded_at` is a real timestamp from the wrong table, so there is no
error and nothing in the logs indicates a problem — the source simply passes, warns, or errors
based on another table's modification time.

This happens when sources point at different projects (database) that use the same dataset
name (schema). Batch freshness collapses them: all source relations end up in a single
batch, that batch is looked up inside one project's `INFORMATION_SCHEMA` and results are
matched back to sources on (schema, identifier) with the database discarded.

The result is nondeterministic. Which project the batch queries depends on which relation
lands at `relations[0]`, and that varies between otherwise identical invocations — so the same
source flips between correct and incorrect freshness from run to run (evidence below).

Two further notes on scope:

- The colliding table does not need to be declared as a source. A physical table with a
matching `schema.table_name` in the queried project is enough to answer for a declared source
in a different project. Removing the other source declaration does not fix it.
- Silent incorrectness is the bigger concern, not the failures that make it visible. A source
whose twin in the other project is updated normally will pass freshness indefinitely while the
real table goes stale.

### Expected Behavior

Source freshness should be scoped to the specified database/project.

### Steps To Reproduce

See detailed reproduction steps in the original ticket: https://github.com/dbt-labs/dbt-adapters/issues/2107

### Relevant log output

```shell

```

### Environment

```markdown
- OS: macOS (arm64)
- Python: 3.12.13
- dbt-adapters: dbt-core==1.12.0b2 + dbt-bigquery==1.11.3
- Also observed on dbt Cloud's "Latest" release track (2026.7.28+709584c), where the behavior flag is enabled by default. This is how we first hit it in production.
```

### Which database adapter are you using?

bigquery

### Is this a discrepancy vs. dbt 1.x?

- [ ] Yes — this works in dbt 1.x but not in dbt v2.x

### Additional Context

See original ticket: https://github.com/dbt-labs/dbt-adapters/issues/2107