URL/RegExp not resolvable as types unless tsconfig has matching lib

[milkyskies]

Repro

In a Floe project whose tsconfig.json does not include `"dom"` in `compilerOptions.lib`:

```floe
type User = {
avatarUrl: Option,
}
```

→ `unknown type `URL`` (E002).

The hover for `URL` shows the stdlib module surface (`URL.parse`, `URL.host`, etc. — added in #1426) but the type system doesn't know what `URL` means as a type annotation.

Root cause

`crates/floe-core/src/stdlib/url.rs` (added in #1427) registers functions like `URL.parse(string) -> Result<URL, ParseError>` whose signatures reference `Type::Named("URL")`. But `crates/floe-core/src/checker/type_resolve.rs:257` only accepts a name as a type if it's in `self.ambient_types` — populated from TS lib `.d.ts` files based on tsconfig's `compilerOptions.lib`.

`URL` lives in `lib.dom.d.ts`. `Date` lives in `lib.es5.d.ts` (loaded by default), which is why `Date` works.

So `URL` only resolves as a type when the project happens to enable DOM lib. For a server-only project with `"lib": ["es2022"]`, `URL` becomes an unresolvable type even though the stdlib module says it's the Floe-side surface for it.

Same applies to `RegExp` and `URLSearchParams` (also added in #1427) — they're in `lib.es5.d.ts` so usually OK, but the same fundamental bug.

Fix

Stdlib modules that represent runtime types Floe owns (URL, RegExp, URLSearchParams) should be auto-registered as known type names independent of ambient. One approach: extend `StdlibRegistry` with a `type_modules: HashSet` for modules whose name is also a valid type, and check it in `type_resolve.rs` before falling through to the ambient/utility branches.

Tests

• `url_type_annotation_resolves_without_dom_lib` — set tsconfig with `"lib": ["es2022"]` only, `type X = URL` should not error.
• Same for `RegExp`, `URLSearchParams`.

Priority

P2. Visible to anyone using URL on a non-DOM project.