Improve error reporting for boolean attribute syntax errors

[andrewmd5]

Description
When encountering boolean attributes with incorrect syntax (missing # prefix), the parser currently backtracks and produces a confusing error message about plain identifiers in an unrelated location. This makes debugging more difficult, especially since the VSCode syntax highlighting can make the incorrect syntax appear valid.

Current Behavior
Given this snippet:

env {
  var1 value1
  var2 value2
}
file "My File" type=file required=true {
  description "File to be transformed"
  value $workflow.file
}

The parser produces this error:

Error:
  × Expected a valid node entry.
    ╭─[11:8]
 10 │ env {
 11 │   var1 value1
    ·        ───┬──
    ·           ╰── plain identifiers can't be used here
 12 │   var2 value2

The error points to value1 in the env block, rather than the actual issue: required=true should be required=#true.

Expected Behavior
The parser should detect and report the missing # prefix for boolean attributes directly. For example:

Error:
  × Invalid boolean attribute syntax
    ╭─[line:col]
    │ file "My File" type=file required=true {
    ·                            ───┬──────
    ·                               ╰── boolean values must be prefixed with '#'
    ╰────
  help: Use 'required=#true' instead of 'required=true'

Additional Context

• The VSCode extension's syntax highlighting treats boolean keywords specially, which can mask this syntax error visually
• This type of error can be particularly confusing for new users who are familiar with other config formats where boolean values don't require special prefixes
• Improving the error message would help users identify and fix the issue more quickly

Possible Solution
Add specific error detection for boolean attributes without the # prefix, rather than falling back to generic parsing rules that result in unrelated error messages.

Let me know if you would like any additional information or clarification!

[zkat]

I finally got some time to look at this and: this isn't the v2 parser doing this. It's the v1 parser.

How are you parsing this file? Only KDL >6.0.0 is able to parse v2. The first error you showed is indeed, correct, when a file is being parsed in v1 mode.