INET encounters conversion errors if INET isn't referenced prior to use.

I assume this is due to lazy loading of the extension, but this causes unexpected issues from a developer point of view.

expected behavior: INET values are converted properly immediately on opening a database without having to manually initialize the inet extension.
```
$> duckdb example.db
-- Loading resources from ~/.duckdbrc
DuckDB v1.3.2 (Ossivalis) 0b83e5d2f6
Enter ".help" for usage hints.
D CREATE TABLE IF NOT EXISTS tbl (cidr INET);
D INSERT INTO tbl VALUES ('107.189.1.83');
D .exit
$> duckdb example.db
-- Loading resources from ~/.duckdbrc
DuckDB v1.3.2 (Ossivalis) 0b83e5d2f6
Enter ".help" for usage hints.
D INSERT INTO tbl VALUES ('107.189.1.83');
Conversion Error:
Type VARCHAR with value '107.189.1.83' can't be cast to the destination type INET

LINE 1: INSERT INTO tbl VALUES ('107.189.1.83');
^
D CREATE TABLE IF NOT EXISTS tbl (cidr INET);
D INSERT INTO tbl VALUES ('107.189.1.83');
```

Reproduce the conversion error in the DuckDB CLI using the reopening sequence shown, with the INET extension not explicitly initialized. Start by tracing how the inet extension is loaded and how VARCHAR values are converted to INET; done means the second-session INSERT succeeds without manual extension initialization.

Written by the indexing model from the issue text.