fix(parser): reject whitespace-only scope

[svyatov]

feat( ): x parses today with a scope of " ". Spec rule 4 requires a scope to be "a noun describing a section of the codebase", and a value with no non-whitespace character is not one. @wesleytodd confirmed on #39 that this was unintended and pointed at the guard in scope(), which is the line this widens.

The change

node.value === '' becomes node.value.trim() === ''. Rejection reuses the existing abort path, so feat( ): x now fails exactly the way feat(): x already did, with the error pointing at the space.

trim() rather than the local isWhitespace from lib/type-checks.js, because trim() also covers <USP>, the Unicode Space_Separator class that the README grammar lists at line 59 but isWhitespace omits. Scopes cannot contain newlines, so trim() stripping line terminators does not matter here.

What deliberately did not change

Padded scopes still parse, padding included:

parser('feat( parser ): x')   // scope " parser "
parser('feat(http parser): x')  // scope "http parser"

Rule 4 constrains the noun, not the space around it. Rule 9 shows the spec bans whitespace explicitly where it means to ("A footer's token MUST use - in place of whitespace characters"), and no such clause exists for scope. Rejecting padding would be my judgement rather than the spec's, so I left it out. Happy to add it if you read rule 4 more strictly.

Blast radius

Only whitespace-only scopes change verdict. A body line that looks like one still falls back to text rather than failing the parse, because the rejection rewinds:

parser('fix: address major bug\n\nfoo( ) bar')  // body <text>, no throw

Tests

Three, all plain assertions so test/parser.js.snap stays untouched. One fails without the parser change; the other two pin the padded-scope and body-fallback behavior above and pass either way, on purpose.

Locally the suite goes from 34 passing to 37, standard stays clean, and npm run coverage clears the .nycrc thresholds.

Closes #39