Database queries with an Option now find your rows

[nz]

Fixes #44.

If you put an Option into a where query, the SQL compared against NULL, which never matches anything. The query quietly found zero rows and never raised. Now the value comes out of the Option before the query is built, so the query finds your rows. A None now asks for IS NULL, which is what SQL needs to find empty columns.

Detail

• Hash conditions never reach the two existing quoting prepends: the value flows through PredicateBuilder#build → build_bind_attribute → Relation::QueryAttribute → type.serialize, which casts an unrecognized object to nil (activerecord 8.1.3, predicate_builder.rb:57,67, query_attribute.rb:28).
• Fix: Errgonomic::Rails::ActiveRecordPredicateBuilder prepended onto ActiveRecord::PredicateBuilder, unwrapping at #build — the single point every hash condition passes. Some(v) binds as v, None as nil (Arel renders IS NULL), and arrays unwrap one level, since where(col: [Some(1), Some(2)]) previously produced IN (NULL) via an ArrayHandler path that bypasses bind attributes entirely.
• None in where previously worked by accident: QueryAttribute#nil? consults the value's own nil?, which the None#nil? compromise answers. Now pinned by a test instead of luck.

Known gaps, deliberately out of scope: string-fragment conditions (where("x = ?", Some(1))) raise loudly but with a confusing message; association-key conditions (where(author: Some(record))) route through AssociationQueryValue before #build and are untested, probably still broken; Ranges of Options and nested arrays are not unwrapped.

Tests: Some matches the row and to_sql contains no = NULL; None yields IS NULL and matches; array of Somes yields IN (1, 2).

[lutzcc1]

Cool