Support structured control flow (loops) in Bash and PowerShell grammars

Problem

SPEC.md section 4 states v0.1 does not support control-flow keywords. for, while, do, done, then, fi, case, and esac set IsUnparseable = true.

The grammar is flat:

command := clause (compound_op clause)*

This is load-bearing for real consumers. NetClaw's shell approval gate walks parsed clauses to decide authorization. Commands that hit IsUnparseable fail closed to an approval prompt.

Why it matters

LLM agents emit loops and heredocs constantly. A production corpus of 45 approval-prompted shell commands showed 8 (18%) were for loops, heredocs, or process substitution. All tripped IsUnparseable.

Loops are static constructs. for f in *.txt; do rm "$f"; done does not hide a path behind $(). The approval risk is the body clause (rm). The existing clause model already evaluates that.

Request

Support structured control flow in both grammars:

• Bash: for / while / until / if / case with do / done / then / else / fi / esac
• PowerShell: foreach / for / while / do / if / switch

Design intent: parse the loop header and expose body clauses as child clauses in the AST. The loop keyword adds no authorization scope. Consumers (approval gates) can walk body clauses with the same logic they use for && chains.

Priority

Corpus-based order for Bash: for loops first, then heredocs, then while / if. Also consider arithmetic expansion $(( ... )), which the same spec line excludes.

Bắt đầu với mục 4 của SPEC.md và ngữ pháp lệnh/mệnh đề phẳng hiện có cho cả Bash và PowerShell. Theo dõi cách IsUnparseable được thiết lập và cách AST cung cấp các mệnh đề, sau đó xác minh rằng các cấu trúc có cấu trúc được liệt kê tạo ra các mệnh đề body con mà các consumer của approval-gate có thể duyệt qua mà không kích hoạt IsUnparseable.