Does DuckDB back-fill existing rows when ALTER TABLE ADD COLUMN includes a DEFAULT?

I'm designing a schema migration for a DuckDB database (assuming a recent stable release, e.g. 1.x) and need to add a non-nullable-style column to a large existing table. My understanding from the documentation is that ALTER TABLE t ADD COLUMN c INTEGER DEFAULT 0 records the default as schema metadata, but existing rows still read as NULL until an explicit UPDATE runs.

The uncertainty is about the intended trade-off on a table with hundreds of millions of rows. If the default is metadata-only, then filling the column requires either a full UPDATE or a CREATE TABLE AS SELECT rewrite, both of which could spike memory and disk I/O. I want to confirm the exact semantics before choosing between those two approaches, and to know whether any catalog view (e.g. DESCRIBE or pragma_table_info) distinguishes a stored value from a not-yet-materialized default.

Specifically:

• Is it correct that DuckDB never back-fills existing rows on ADD COLUMN ... DEFAULT, and the default only applies to rows inserted afterwards?
• For populating the column on a very large table, is a batched UPDATE or a full table rewrite the safer option regarding memory pressure?
• Is there a documented way to verify which rows still hold NULL versus the applied default after migration?