t27c typecheck prints recursive-struct warnings in HashMap order (output differs run to run) #7283

Problem

t27c typecheck lists its "recursive struct" warnings in HashMap order, so the same binary on the same file prints them in a different order on different runs.

Measured on the Railway lab, 2026-10-07, the #7242 build (403b27f plus #7242), six runs of t27c typecheck specs/bus/pubsub.t27: 2 distinct outputs (5 runs one md5, 1 run another). The only difference is where the line warning: recursive struct 'TopicNode' detected falls among the other warnings. compiler/ast.t27 does the same with SymbolTable.

Why it matters

Every A/B of t27c output (old binary vs new on the whole corpus, as #7242 and #7281 were measured) reports these files as changed when nothing changed. Each such report needs a hand check to call it noise. A tool that diffs typecheck output (a ratchet, a seal, a cache key) inherits the flake.

Cause

bootstrap/src/compiler.rs (around line 25754 on master df00ec4): the cycle check builds struct_fields: HashMap<String, Vec<String>> and loops for sname in struct_fields.keys(). A HashMap with the default RandomState hasher iterates in a different order on each run.

Fix

Loop over the struct declarations in source order (ast.children filtered to NodeKind::StructDecl) and keep the map only for lookups. The warning set stays the same; only its order becomes fixed.

compiler.rs is sealed (FROZEN_HASH), so the fix moves the seal as the compiler's other edits do.

Acceptance

• for i in 1 2 3 4 5 6; do t27c typecheck specs/bus/pubsub.t27 2>&1 | md5sum; done | sort -u | wc -l prints 1.
• The same for compiler/ast.t27.
• The warning count of typecheck over the corpus is unchanged.

Found during the #7281 corpus A/B.

🤖 Generated with Claude Code

Boundary

• compiler/ast.t27
• specs/bus/pubsub.t27
• bootstrap/src/compiler.rs

User Scenarios

• Given a spec file containing recursive structs (e.g., specs/bus/pubsub.t27 with TopicNode), when running t27c typecheck multiple times on the same file, then the warning lines for recursive structs appear in the same order every run.
• Given the compiler's own AST spec (compiler/ast.t27) which triggers a recursive-struct warning for SymbolTable, when running t27c typecheck six times consecutively, then all six runs produce identical output (same line order, same md5).

Requirements

• FR-001: The cycle detection in bootstrap/src/compiler.rs MUST iterate struct declarations in source order (as they appear in ast.children filtered to NodeKind::StructDecl) instead of HashMap key order.
• FR-002: The struct_fields HashMap MUST be retained only for field lookups during cycle detection; iteration order MUST NOT depend on it.
• FR-003: The set of recursive-struct warnings emitted MUST remain identical; only their printed order MUST become deterministic.
• FR-004: The change MUST not alter the total warning count emitted by t27c typecheck over the full corpus.