Find falls back to DbBase.Context singleton when no context passed

DbBase.Find<T> now uses db ?? Context, and Client.FindByName's context
parameter becomes optional — call sites read like Client.FindByName("Jane
Doe") without context threading. A null result now overwhelmingly means
"no match"; the residual "no context configured at all" ambiguity is
documented in remarks as part of the ActiveRecord-leak cost this exercise
illustrates.

src/Before.Console/Program.cs

@@ -6,7 +6,8 @@ using Before;
 // The console app sets DbBase.Context (the shared singleton) once at startup,
 // then creates client/order entities, saves them through the context, and
 // queries back using the ActiveRecord entry points:
-//   • Client.FindByName(name, context)
+//   • Client.FindByName(name) — no context argument: rides the
+//     DbBase.Context singleton
 //   • listing via DbBase.Context!.Tracked
 // ---------------------------------------------------------------------------
 
@@ -42,7 +43,11 @@ foreach (var client in DbBase.Context!.Tracked.OfType<Client>())
 
 // ----- find by name -------------------------------------------------------
 Console.WriteLine("\n=== Find by Name ===");
-var found = Client.FindByName("Jane Doe", DbBase.Context);
+// No context argument: FindByName falls back to the DbBase.Context singleton.
+// This is the ActiveRecord ergonomic — call sites don't carry the context,
+// but the null that comes back on a miss can't tell "no such client" from
+// "nobody configured the context".
+var found = Client.FindByName("Jane Doe");
 if (found is not null)
 {
     Console.WriteLine($"Found: {found.Name} [{found.Id}]");