Feature Request: Expose the owning connection (or a stable connection identity) on DuckDBPyRelation

[FBruzzesi]

Follow-up to discussion #580.

Problem

A library that receives a DuckDBPyRelation from its caller cannot reach the connection that relation belongs to. Two consequences, both hit in Narwhals:

1. We cannot follow DuckDB's own threading guidance on the user's behalf: the multiple threads guide says each thread must call .cursor() on the connection. Holding only a relation, there is nothing to call it on.

2. We cannot anticipate the cross-connection error with a useful message: join, union and cross all raise:

   Invalid Input Error: Cannot combine LEFT and RIGHT relations of different connections!
   

Our API takes two user-supplied frames and combines them internally, so this surfaces from deep inside our call stack with no indication that the cause is which connection each frame came from.

What would help

Either of:

• a read-only DuckDBPyRelation.connection property, which solves both cases; or
• a narrower rel_a.same_connection_as(rel_b) predicate, which solves only (2) but exposes no connection mutation.