agent: Add more Rust code examples, update TODO check (#28737)

Release Notes:

- N/A

crates/eval/examples/lhs_join_update_callbacks/base.toml

@@ -0,0 +1,3 @@
+url = "https://github.com/clockworklabs/SpacetimeDB.git"
+revision = "68d23d4c25548fd74f1bde28a57d8858022b9671"
+language_extension = "rs"

crates/eval/examples/lhs_join_update_callbacks/criteria.md

@@ -0,0 +1,6 @@
+1. A `JOIN` query with conditions on both sides (LHS and RHS) correctly triggers subscription updates when only the LHS table is updated.
+2. Callback functions (`on_insert`, `on_update`) are invoked exactly once and in the expected order.
+3. Queries with logically equivalent WHERE conditions (e.g., `x > 0 and x < 5` vs. `0 < x and x < 5`) yield consistent subscription behavior.
+4. Complex disjoint queries that restrict the RHS via additional constraints (e.g., `u.n != 1`) still properly identify matching LHS updates.
+5. Type inference and expression normalization correctly handle literals on the left-hand side of binary operations in WHERE clauses.
+6. Physical execution plans normalize expressions like `3 < l.x` into `l.x > 3` with appropriate operator inversion (`Lt ↔ Gt`, `Lte ↔ Gte`), maintaining logical correctness.

crates/eval/examples/lhs_join_update_callbacks/prompt.md

@@ -0,0 +1,12 @@
+Add a new test case to validate join subscription updates when the **LHS table is updated**, and ensure correct invocation of reducer callbacks. The test should:
+
+- Subscribe to a join query with a filter involving fields from both tables (e.g., `SELECT p.* FROM pk_u32 p JOIN unique_u32 u ON p.n = u.n WHERE u.data > 0 AND u.data < 5`).
+- Insert rows into both LHS (`pk_u32`) and RHS (`unique_u32`) that satisfy the join condition.
+- Verify the initial subscription callback is triggered via `on_insert`.
+- Update the LHS (`pk_u32`) such that the row remains part of the join result.
+- Validate that:
+  - `on_update` is invoked correctly.
+  - An immediate follow-up update back to the original value also triggers `on_update`.
+- Repeat the above with disjoint filters (e.g., `u.n != 1`) and confirm behavior remains correct.
+
+Also, ensure that literal-first SQL expressions like `3 < x` are correctly interpreted and inverted in the physical execution plan (converted to `x > 3`) and behave identically during query evaluation and execution.