test(sql-orm-client): clarify the FK-include control case in the M:N suite

The test asserting that a 1:N FK include still lowers without a junction
join carried an opaque name ("FK include path is unchanged (no
regression)") that didn't say what it checks or how it relates to M:N.
Rename it to state the asserted lowering and add a comment marking it as
the control case for the junction-join branch — it pins that the branch
fires only for N:M relations and never leaks into the FK include path.

Signed-off-by: Alexey Orlenko's AI Agent <robot@aqrln.net>

Author: tensordreams

packages/3-extensions/sql-orm-client/test/query-plan-select.test.ts

@@ -759,7 +759,13 @@ describe('M:N include correlated subquery', () => {
     );
   });
 
-  it('FK include path is unchanged (no regression)', () => {
+  // Control case for the M:N lowering above: an ordinary 1:N FK include
+  // (users → posts, joined by posts.user_id = users.id) must still lower to a
+  // correlated subquery whose child SELECT has NO junction JOIN and correlates
+  // with a plain WHERE on the child's FK column. This pins that the
+  // junction-join branch fires only for N:M relations and never leaks into the
+  // FK include path.
+  it('1:N FK include lowers to a child-FK WHERE with no junction join', () => {
     const { collection } = createCollection();
     const state = collection.include('posts').state;
 
@@ -773,7 +779,6 @@ describe('M:N include correlated subquery', () => {
     expectDerivedTableSource(childRowsSelect);
     const childSelect = childRowsSelect.query;
 
-    // FK path: no JOIN to junction, just WHERE on child FK
     expect(childSelect.joins ?? []).toHaveLength(0);
     expect(childSelect.where).toEqual(
       BinaryExpr.eq(ColumnRef.of('posts', 'user_id'), ColumnRef.of('users', 'id')),