[kpal81xd]

Fixes #73

Three robustness problems in ScriptParser.extractAttributes when an attribute's type isn't a supported type:

1. Tuple @type ({[number]}, {[number, number]}): the tuple type has no symbol, so symbol.declarations threw a TypeError.
2. Empty object initializer (data = {}, including on an @interface member with a JSDoc comment): the widened type has no members, so Array.from(undefined) threw.
3. Unresolvable @type ({Missing}, {Missing[]}, {{}}): the type has no declaration, so the member was skipped with no error.

1 and 2 threw out of the parser, so the whole file returned no attributes and no diagnostics.

Changes

• Types with no declaration now fall through to the existing "…" is not a valid attribute type error instead of throwing or being skipped.
• An empty {} initializer no longer counts as an initialized object literal, so it gets the same error.
• Add type.invalid.js regression coverage. It puts all cases in one script next to a valid attribute and an interface attribute, so it also checks that the rest of the script still parses.

Note: attributes that were previously dropped silently now show an error, which is the intended outcome of 3.

Manual smoke test

1. In an ESM script, add /** @attribute @type {[number]} */ values; alongside a valid /** @attribute */ speed = 1;, then parse.
   • Expected: one "is not a valid attribute type" error on values; speed still appears in the inspector.
2. Replace it with /** @attribute */ data = {}; and parse.
   • Expected: one "is not a valid attribute type" error on data; other attributes still appear.
3. Replace it with /** @attribute @type {Enemy[]} */ enemies; where Enemy is not defined or imported, then parse.
   • Expected: a "{Enemy[]}" is not a valid attribute type error shown in the problems list, instead of the attribute silently missing.