ide-template: JavaLiterals and JsLiterals read a quoted numeric default differently - the dialog seeds 20, the repository throws NumberFormatException (#7207 follow-up)

[delchev]

Describe the bug

PR #7255 (#7207) introduces AuthoredDefaults with this contract (ide-template/.../model/AuthoredDefaults.java:14-19):

One authored default is written into several generated languages - the repository's Java literal (JavaLiterals) and the item dialog's JavaScript seed (JsLiterals) - and every one of them has to read the authored text the same way, or the value the column holds and the value the form offers stop agreeing.

They do not read it the same way for a quoted numeric default. JsLiterals.defaultValueExpression unquotes first (JsLiterals.java:96-100; the PR's test pins '20' -> 20). JavaLiterals.defaultValueExpression unquotes only in the String arm (JavaLiterals.java:81-89):

case "java.math.BigDecimal" -> "new java.math.BigDecimal(\"" + escape(defaultValue) + "\")";
case "Long"    -> "Long.valueOf(\"" + escape(defaultValue) + "\")";
case "Integer" -> "Integer.valueOf(\"" + escape(defaultValue) + "\")";
...
case "String"  -> "\"" + escape(AuthoredDefaults.unquote(defaultValue)) + "\"";

So defaultValue: "'20'" on an integer column (the shape the JS side explicitly supports) seeds 20 in the item dialog and emits Integer.valueOf("'20'") in the repository - a NumberFormatException on every create that relies on the default. Rare shape, but it is the class's own stated invariant, and the JS half was written to accept it.

Expected

JavaLiterals unquotes through AuthoredDefaults.unquote in every arm (then validates that a numeric arm's text parses as a number at generation time, refusing an unparsable default loudly instead of emitting a literal that throws at runtime). A JavaLiteralsTest case for '20' beside the JsLiterals one.