[stack 16/20] spec(gazprea): remove struct field forbidden by struct's own rule

[Sir-NoChill]

Origin: spec-patches/05-fix-struct-nesting.patch (backlog audit).

What

gazprea/spec/types/struct.rst — the Another example in Declaration violated two rules stated a paragraph earlier and elsewhere in the spec:

1. struct-in-struct forbidden: the chapter opening says "Any type except tuple, another struct and streams may be stored within a struct", yet Another contained an s1 struct_field. Removed.
2. string[N] is not a valid type spelling: per types/string.rst, strings have no size specifier. Changed string[256] str → character[256] str.
3. type-name typo: prose said "Struct type s has three fields" — should be s1. Corrected.

The prose that enumerated Another's fields is updated to match (four → three named fields; struct_field dropped).

Audit — ambiguities for reviewer attention

• string vs character[N]: patch prefers character[256] to model a fixed-length string-like field. If Gazprea does support sized strings elsewhere (or if the intent was a variable-length string with a bounding hint), the correct fix is different — either string (unsized) or a normative addition to the string chapter. Confirm which is intended.
• struct-in-struct ban: if the "no nested structs" rule is actually intended to be relaxed (matching what the Another example suggested), the fix is the other direction — keep s1 struct_field and amend types.rst and the chapter opening. Reviewer's call which is normative.
• Composes cleanly with #122 — that PR's new paragraph refers only to t1 and t2, not the removed struct_field.

Stack

Depends on #126; part of stack #121.

🤖 Backlog patch applied by Claude Code

[Sir-NoChill]

Collapsed into #139 — a single consolidated PR of the whole stack (all 40 commits preserved). The flagged questions from this PR are aggregated in #139's description; this branch and thread remain here for reference. Closing in favour of #139.