fix: detect parsePlPgSQL errors by non-JSON result instead of message prefix

[pyramation]

Summary

wasm_parse_plpgsql returns error messages as plain strings, but the JS side only recognized errors prefixed with syntax error/deparse error/ERROR. Any other PostgreSQL error message (e.g. RETURN cannot have a parameter in function with OUT parameters, "x" is not a known variable) fell through to JSON.parse and surfaced as a confusing Unexpected token 'R', "RETURN can"... is not valid JSON SyntaxError, swallowing the real message.

Since a successful parse always returns a JSON object ({"plpgsql_funcs":...}), parsePlPgSQL/parsePlPgSQLSync now treat any result not starting with { as an error:

- if (resultStr.startsWith('syntax error') || resultStr.startsWith('deparse error') || resultStr.startsWith('ERROR')) {
+ // Success is always a JSON object; anything else is an error message
+ if (!resultStr.startsWith('{')) {
    throw new Error(resultStr);
  }

Changed in templates/full/index.ts (source of truth) and the generated versions/18/src/index.ts. This was issue #1 in the earlier libpg-query@18.1.0 PL/pgSQL bug report; fingerprint/normalize keep their prefix checks since their success values are plain strings.

Link to Devin session: https://app.devin.ai/sessions/064ad193e1c040af8c145d55e07af9b8
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring