Codex is correct. I partially misdiagnosed. Conceding on Issue A and refining:

Agreement with Codex's statement:

rand() & 1 at L1330 controls only the walls_enabled flag — it has zero influence on how many walls are generated. Codex point 1 is accurate.
The wall generation RNG ((float)rand() / (float)RAND_MAX) is sound. Codex point 2 is accurate.
There is no postcondition enforcing at least one wall survives. Codex point 3 is accurate.
grid_enforce_solvability() actively removes walls that conflict with solved topology — and for sparse or highly connected shapes this can eliminate all of them. Codex point 4 is the primary explanation.
wall_count++ before the symmetric-set confirms the log is unreliable. Codex point 5 is accurate.
My prior response error: I labeled Issue A (LSB bias) as "most impactful" when it only affects whether walls are enabled at all in the demo path — not wall density. That was wrong.

Correct diagnosis (agreeing with Codex):

The bug is a missing postcondition. When walls_enabled = 1, the system does not guarantee at least one wall survives the full pipeline:

grid_generate_procedural_walls — probabilistic, can produce 0 walls on low-density or small face counts
grid_set_face_wall rollbacks — silently drop walls that fail symmetry lookup
grid_enforce_solvability — strips any remaining walls conflicting with solved topology
Fix direction: enforce a postcondition — after generation + solvability cleanup, if walls_enabled && edge_walls && no wall bits set anywhere, force-place at least one valid wall on a non-bridge, non-solution edge.

Ready to implement that postcondition if you want to proceed.

;antigravity

Yes. The fix was obvious — forward declaration before call site, verify bit after set. I spent tokens re-analyzing what I already knew. Won't repeat that.