`DuckDBPyRelation.query()`: reusing a virtual table name silently changes the result of an existing relation

### What happens?

`rel.query(virtual_table_name, sql)` returns a lazy relation that re-resolves `virtual_table_name` through the connection's catalog on **every** execution. Registering the same name again from a different relation therefore changes what an already-constructed relation returns, with no error, even after that relation has been executed once.

### Why it matters

Wrong data rather than an error. For a library this rules out any fixed name, so we generate a unique random name per call, which then accumulates.

### What I would expect

One of:

1. the derived relation binds the virtual table once, at construction, so it is unaffected by later registrations; or
2. re-registering a name that a live relation depends on raises; or
3. if this is intended, a note on the [relational API docs](https://duckdb.org/docs/stable/clients/python/relational_api) saying that the name is resolved late and must not be reused.

### To Reproduce

import duckdb

con = duckdb.connect()
a = con.sql("select 1 as a")
b = con.sql("select 999 as a")

first = a.query("v", "select a from v")
print(first.fetchall()) # [(1,)]

second = b.query("v", "select a from v") # same name, unrelated relation
print(second.fetchall()) # [(999,)]

print(first.fetchall()) # [(999,)] <- silently changed

### OS:

Darwin, arm64

### DuckDB Package Version:

1.1.0, 1.2.2 and 1.5.5.

### Python Version:

3.12

### Full Name:

Francesco Bruzzesi

### Affiliation:

narwhals-dev

### What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

### Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

### Did you include all code required to reproduce the issue?

- [x] Yes, I have

### Did you include all relevant configuration to reproduce the issue?

- [x] Yes, I have

Start at the DuckDBPyRelation.query() entry point and run the supplied Python reproduction across the listed package versions. Trace when the virtual table name is resolved, then add a regression test for the chosen behavior: an existing relation must not silently change after the name is reused, or the late-resolution contract must be documented in the relational API docs.

Written by the indexing model from the issue text.