0.21.0 Correct or Error: two P0s (join NULLs, DDL data loss) and a client-reachable DoS class

[zvndev]

First release of the road-to-1.0 plan (#197). Every known silent-wrong-answer and client-reachable availability bug in the tree is now a fix or a typed error.

Two P0s, both reproduced against the shipped 0.20.0 binary first

Unqualified columns in a join returned a row of NULLs.

User join Order on User.id = Order.user_id { .name, .amount }
 name | amount          ->  ada  | 50
 NULL | NULL                ada  | 70

Validation accepted a bare field name on the strength of a runtime suffix match that evaluation never implemented. The 0.20.0 round that was meant to end silent wrong answers did not reach join scope. One resolver now serves projection, filter, join-key and sort, replacing three that disagreed; an ambiguous bare name is a typed error, not a silent pick.

DDL inside a transaction destroyed data while reporting success.

begin; drop Keep; rollback   ->  "transaction rolled back"
count(Keep)                  ->  Error: table 'Keep' not found   # gone, across a restart

Now refused at every DDL entry point including drop view, which additionally orphaned the backing table and poisoned the name permanently.

Also fixed

• Unbounded per-transaction dirty page set could OOM the process under panic = "abort". Now budgeted, configurable via POWDB_DIRTY_PAGE_BUDGET
• Parse failures and unauthorized writes took a writer permit, letting a read-only principal hold all 1024
• Window sum reported a false overflow where scalar sum succeeded
• Aggregates over non-numeric values answered 0; integer overflow clamped to i64::MAX
• Arithmetic on non-numeric operands yielded NULL; date_add/date_diff/abs used unchecked arithmetic
• Errors reached drivers as Internal, the class meaning "server bug, not your fault"
• The miri job had been passing without running: it filtered on a module that does not exist, and a cargo filter matching nothing exits 0

Known limitation, documented not hidden

An update can durably store NULL in a required column while insert refuses the same value. PowDB has no statement-level atomicity, so a per-row refusal mid-statement produces a torn write. That refusal was implemented, measured to tear a multi-row update across a reopen, and deliberately reverted. Statement atomicity is the real fix and belongs in the assurance release. docs/STABILITY.md carries the reproduction.

Process

Three rounds. Adversarial verifiers rejected 3 of 4 lanes in round 1, including a data-corruption regression whose own test hid it behind a one-row fixture, and caught a newly introduced silent wrong answer in round 2 where a projection alias suppressed the ambiguity guard for a sibling field. Every fix was mutation-tested by reverting it and confirming the test fails.

Suite 1837 passed, 0 failed. Clippy and fmt clean.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}