fix: DSR replies to bare CSI n (missing default status-report parameter)

[pocketprobe]

DSR (CSI Ps n) declared no defaultParameters, so a bare CSI n (Ps omitted → args[0]==0) matched neither the args[0]==5 (status) nor args[0]==6 (CPR) branch and produced no reply. A guest sending a bare status query then hangs waiting for \033[0n that never comes (§36 m4).

What this does

• Add defaultParameters returning {5}. CSIManager substitutes a 0/omitted slot with the handler's declared default before execute runs (it iterates defaults.length, so the default fires even at argCount==0), so bare CSI n resolves to Ps=5 → \033[0n. This matches ECMA-48 / common terminal behavior (Ps=0 treated as Ps=5 for status).
• Unchanged: CSI 5 n (args[0]==5, no substitution), CSI 6 n (CPR), and the CSI ? n (DECDSR) path.
• One method + a comment; matches DSR's existing minimal handler style (no class Javadoc, bare execute params — same group as CHA/VPA/DA).

Verification

• 2 new tests in TerminalBufferTest, 102/0. dsrBareCsiNRepliesStatus (bare CSI n → \033[0n) and dsrExplicitFiveStillRepliesStatus (explicit 5 unchanged), reading the reply via terminal.io.getInput().
• Revert-and-fail proven: removing defaultParameters fails the bare-CSI-n test (no reply → assertNotNull fails).
• Clean build (compileJava + compileTestJava ran, not cached); full suite green.

QA gate

• PMD main 0 (preserved the zero-violation baseline from the recent refactor); Checkstyle 0 in touched files (the 1 main warning is pre-existing in DeltaFrameCodec.java); SpotBugs delta 0.

Assisted by: GLM (syn:large:text on synthetic.new) — code generation and review.