Type handlers: runtime SqlMapper.AddTypeHandler registrations honored end-to-end

[mgravell]

The biggest remaining behavioral class. Design and probed facts in notes/typehandlers-design.md (committed here); the short version is the delegate-to-vanilla doctrine applied to runtime-mutable state — the generator cannot see AddTypeHandler calls at compile time, so generated code defers to vanilla's own decision procedure at execution time:

• Writes: a member type the generator doesn't recognize dispatches through SqlMapper.LookupDbType (public, CS0618-suppressible — the same tier as PackListParameters). Handler present → handler.SetValue, passing DBNull for null (never null itself — TypeHandler<T>'s interface impl NREs on the struct cast; probed, and vanilla coalesces too). Otherwise any returned DbType applies and the value binds raw exactly as before (demand: false deliberately: modern providers natively handle types vanilla's map doesn't — DateOnly, until the Dapper re-enable ships). Expandable members check the handler first — a handled collection type must not list-expand (Issue253), which is the order vanilla applies. Update-mode mirrors the dispatch, so command reuse stays legal (the parameter shape is stable).
• Reads: the lib deliberately doesn't reference Dapper (a consumer may use Dapper or Dapper.StrongName, and a hard reference would load both and split the handler registry — I believe this is why the csproj has that commented-out PackageReference). Generated code installs a TypeHandlerBridge from a module initializer, compiled against the consumer's own Dapper; the flexible read path consults it, and a whole-type handler overrides a generated row factory (RowFactory<T>.Resolve), matching vanilla's handler-before-member-binding order. Down-level targets get a probe-gated ModuleInitializerAttribute polyfill; the whole feature is inert against a Dapper too old to have HasTypeHandler/LookupDbType.
• char/char? and object/dynamic stay excluded from dispatch (padding and runtime-typing respectively); ParamMember gains TypeOfName mirroring RowMember's, because typeof on an annotated reference type (CS8639) or dynamic (CS1962) doesn't compile — found the hard way when the harness build failed silently.

Dapper test suite: 677 → 705/793. The entire runtime-handler family clears (Issue136, Issue1959 ×4, Issue253 ×2, Issue461, SO24740733 ×2, Issue149, the PreferTypeHandlersForEnums test — LookupDbType checks that setting internally, so it came free), plus the bare-DataTable TVP pair and the Xml tests, because vanilla registers DataTableHandler and the XML handlers by default and the dispatch reaches them like any registration.

Deliberately not here (recorded in the design note): AddTypeMap on recognized scalars (the string→AnsiString tests — honoring it costs a per-parameter lookup on the hottest types; explicit trade to discuss), and the SetTypeMap runtime column-mapping family (the parity table's 🚫 proposal stands). Prior art #117 (samcragg) and #162 (7amou3) are the announced-attribute tier — the right shape for static dispatch, and still worth doing as an optimization on top of this, redone on the plain-data model (#162's symbol-keyed registry predates phase 2).

[mgravell]

Two additions from the design discussion: enum parameters no longer pay the lookup unless Settings.PreferTypeHandlersForEnums is actually on (a static bool read guards it; vanilla only consults enum handlers under that setting anyway), and the design note now records the agreed direction — declarative [module: ...] config attributes as the primary spelling (better scoped than the process-global registries they replace, per-assembly and deterministic), with this PR's runtime bridge as the compatibility tier and a strict switch to come. Post-gate cost profile: recognized scalars pay zero, enums pay a field read, one dictionary hit per query for the whole-type check — the remaining per-parameter lookups land only on types that were previously an exception. Suite holds at 705/793.