[ty] Squash false positive logs for failing to find builtins as a real module

I recently started noticing this showing up in the logs for every scope
based completion request:

```
2025-12-11 11:25:35.704329935 DEBUG request{id=29 method="textDocument/completion"}:map_stub_definition: Module `builtins` not found while looking in parent dirs
```

And in particular, it was repeated several times. This was confusing to
me because, well, of course `builtins` should resolve.

This particular code path comes from looking for the docstrings
of completion items. This involves a spelunking that ultimately
tries to resolve a "real" module if the stub doesn't have available
docstrings. But I guess there is no "real" `builtins` module, so
`resolve_real_module` fails. Which is fine, but the noisy logs were
annoying since this is an expected case.

So here, we carve out a short circuit for `builtins` and also improve
the log message.

crates/ty_python_semantic/src/module_resolver/resolver.rs

@@ -265,7 +265,14 @@ fn desperately_resolve_module<'db>(
     let _span = tracing::trace_span!("desperately_resolve_module", %name).entered();
 
     let Some(resolved) = desperately_resolve_name(db, importing_file, name, mode) else {
-        tracing::debug!("Module `{name}` not found while looking in parent dirs");
+        let extra = match module_name.mode(db) {
+            ModuleResolveMode::StubsAllowed => "neither stub nor real module file",
+            ModuleResolveMode::StubsNotAllowed => "stubs not allowed",
+            ModuleResolveMode::StubsNotAllowedSomeShadowingAllowed => {
+                "stubs not allowed but some shadowing allowed"
+            }
+        };
+        tracing::debug!("Module `{name}` not found while looking in parent dirs ({extra})");
         return None;
     };