Don't drop rows for a non-null field under a nullable parent

[phdoerfler]

This PR was mostly done by an LLM. I have poked and prodded at it, encouraged it to verify rather than assume, enforced a proper software engineering workflow including TDD and reviews on top of which I did a manual review. It was an iterative process. The PR is now at a stage where I can't find anything obviously wrong with it but I will admit that the SQL generation is a bit arcane and things might have slipped past me.

And now, without further ado, the detailed LLM analysis:

---

Fixes #888. Also fixes #892, which #888 turned out to depend on.

Three defects, one observable symptom. The first is the one #888 describes: a nested select carrying an INNER join was flattened into the enclosing select's join chain even when it attached via a LEFT join, so the inner join sat below the outer one and eliminated the rows the outer join had null padded. SqlSelect.nest now declines to flatten in that case and builds a subquery instead, which keeps the inner join scoped where it's genuinely valid rather than discarding the optimisation.

Fixing that alone had no effect on MSSQL, which turned out to have a second and older defect, described in #892: an OUTER APPLY was never correlated to its enclosing select, so it behaved as an inner join and discarded the same rows again for an unrelated reason. Laterality.joinPredicates is replaced by distributeJoinConditions, which can rewrite the join as well as yield predicates for the enclosing select, and Apply uses that to wrap the subquery of an OUTER APPLY in a correlating select. Applying the conditions to the subquery's result rather than pushing them into it preserves any LIMIT, OFFSET or DISTINCT, and keeps a same named table inside the subquery from shadowing one of the enclosing select — both of which regressed when tried the other way round.

Correlating once isn't enough, which is the third fix. Nesting a select re-examines joins an earlier nesting already correlated, and correlate didn't recognise the wrapper it had itself built — so it declined, the conditions were lifted a second time, and the correlation was undone. It now recognises that wrapper and leaves the join alone. With that, no query in any of the four backends' suites reaches a decline at all.

None of the three is observable without the others, which is why they're here together: without the first no APPLY is emitted for these queries at all, without the second the first is a no-op on MSSQL, and without the third the second only holds to a depth of one.

Replacing joinPredicates isn't binary compatible, so the last commit bumps tlBaseVersion to 0.30. It's kept separate in case you'd rather own that yourself or take it in a different release.

Worth noting that the issue understates the reach. The join is chosen by !context.tpe.isNullable && !context.tpe.isList, so a list is attached the same way a nullable field is, and a parent with no children at all was being dropped for the same reason: [B!]! with a non-null field beneath B lost every parent whose list was empty. That needs no nullable field anywhere in the schema, so it's the easier of the two to hit by accident. There's a test for each shape.

The tests are a shared mapping and suite run on all four SQL backends, with fixture data including a row whose non-null reference dangles — the case that distinguishes a row being absent from a row being dropped — and a parent with an empty list. A third test descends two lists through a non-null field, which is what reaches the repeated correlation; it needs a second reference back to the parent type, so that the inner list can be empty where the outer one isn't.

One thing deliberately out of scope. A genuinely dangling non-null reference is still not reported as an error: before this change the row vanished from the result entirely, and after it the parent row is returned with the offending field as null. Both are wrong under §6.4.3 step 1, which asks for an execution error propagated to the nearest nullable ancestor. That's a separate defect with a separate remedy — the object field path at SqlCursor narrows without checking, where the interface and union path checks first via narrowsTo — and I'd rather raise it on its own than widen this. The tests assert the post-fix behaviour as it stands, so they'll need updating when it's addressed.

Verified on all four backends: doobiepg, doobieoracle and skunkJVM are green, and doobiemssql is green apart from three pre-existing MovieSuite failures which fail identically at the base commit. Those are a local artifact rather than anything in this change — the container runs in the host's timezone, so moviesShownBetween resolves its range boundary an hour out and returns a fourth film — and they're what #862 pins to UTC.