Errors: render for-in, for-of, and for-await SyntaxErrors

Parent: #899

Problem

Five direct bare exits in parseFor discard the token and grammar rule after the parser has already distinguished:

• the forbidden bare async of lookahead
• in in a for-await head
• using / await using in a for-in head
• an initializer in a sloppy var for-of head
• a classic semicolon head after for await

Executed on current main (78d0d08), eight representative eval probes all produce eval: UnexpectedToken at .... Raw JavaScriptCore 625.1.22 instead reports:

• Unexpected identifier 'of' for for (async of [])
• Unexpected keyword 'in'. Expected 'of' in for-await syntax.
• Unexpected identifier 'x'. Expected either 'in' or 'of' in enumeration syntax. for plain, await-using, and combined for-await using forms
• Cannot assign to the loop variable inside a for-of loop header.
• Unexpected token ';'. Unexpected a ';' in for-await-of header. for empty and declared classic heads

Implementation

• Retain the already-read iteration keyword, using-binding token index, initializer offset, or cached top-level semicolon at each rejection.
• Preserve JavaScriptCore's using-head diagnostic when a using declaration is also nested in for await.
• Match raw JavaScriptCore prose while preserving compact ParseError categories.
• Add no allocation or source rescan to the successful for-loop path.

Verification

• Pin reason, message, and byte offset for every site and the overlapping for-await/using case.
• Add a focused production eval case for all message families.
• Compare exact-parent for-in/of/await and explicit-resource-management test262 subtrees with nonzero denominators and report flips.

Implemented and pushed to main in 40e64ef.

• Bare async of, for-await in, using/await-using for-in heads, sloppy var initializers in for-of, and classic for-await heads now retain their exact rejection context.
• The overlapping for-await/using form preserves JavaScriptCore's using-head diagnostic at the binding.
• Valid loop heads add no allocation or rescan. Locating the top-level semicolon reuses cached tokens only after a classic for-await head has already been rejected.

Validation:

• parser module: 233/233
• focused frontend boundary: 1/1
• raw JavaScriptCore differential: 8/8 byte-identical messages
• exact-parent test262 comparison: 2,280/2,280 before and after across six loop/resource subtrees (0 flips)

This reduces direct return ParseError.UnexpectedToken; sites from 73 to 68.