fix(plpgsql-deparser): bound cursor argument lists and RAISE SQLSTATE conditions

[pyramation]

Summary

Two more round-trip corruption bugs found by sweeping esoteric PL/pgSQL shapes through the downstream round-trip harness — both produced SQL that fails to re-parse:

1. Bound cursors with explicit arguments lost their parameter list.

-- input
DECLARE
  c CURSOR (key int) FOR SELECT * FROM users WHERE id = key;

-- before (invalid: OPEN c(42) against a no-arg cursor)
DECLARE
  key int;
  c CURSOR FOR SELECT * FROM users WHERE id = key;

-- after
DECLARE
  c CURSOR (key int) FOR SELECT * FROM users WHERE id = key;

deparseVar now reconstructs the parameter list from cursor_explicit_argrow (the PLpgSQL_row whose fields[].varno point at the arg var datums), and deparseDeclareSection suppresses those arg vars from standalone DECLARE output.

2. RAISE SQLSTATE 'xxxxx' deparsed as RAISE EXCEPTION 22012 — a syntax error. Condition codes matching /^[0-9A-Z]{5}$/ are now emitted as SQLSTATE '22012', mirroring the existing exception-handler condition logic; named conditions (RAISE EXCEPTION division_by_zero) are unchanged.

Fixtures: Tests 54–56 added to plpgsql_deparser_fixes.sql (+ regenerated generated.json), plus explicit snapshot tests. 104/104 tests pass.

Link to Devin session: https://app.devin.ai/sessions/eeb8deba0c04475091df703c88877302
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