intent: render a posts set constant for its target column's Java type, and print a remedy that survives YAML (#7287)

[delchev]

Follow-up to #7246 / PR #7268: the refusal was right, three of its neighbours were not - all of them the same defect class it set out to close, a posts: set: value that reaches javac as something it cannot compile.

1. The remedy the refusal printed did not work

validatePostSets answered a dotted path with quote it ("Receipt.Store") to mean that text. YAML strips one level of quoting before the parser sees the scalar, so an author who followed that remedy handed the parser the same bare dotted path and got the identical refusal. The spelling that actually reaches PostSetSupport.QUOTED is '"Receipt.Store"' - single quotes wrapping the literal double quotes - which is what the refusal now prints (PostSetSupport.quotedSpelling), with a clause saying why the single quotes are there. QUOTED's own javadoc carried the same misunderstanding and is corrected.

The escape hatch also had no test through the YAML layer. GluePostsTest.theQuotedRemedySurvivesYaml now takes the remedy out of the refusal message, feeds it back through IntentParser.parse, and asserts the rendered "Receipt.Store" string literal.

2. A numeric constant was rendered bare regardless of the target column

Every intent numeric-with-scale type is a java.math.BigDecimal in the generated entity and long is a Long, so Quantity: -3.5 emitted row.Quantity = -3.5; and Sequence: 2 emitted row.Sequence = 2; - compile errors of the whole generated module. Only integer FKs happened to work.

PostSetSupport.targetType now reads the column's type off the target entity - a field by its own spelling (PascalCased on both sides, as the generated assignment is), a to-one relation by its target's key type - and expression renders to it:

column	authored	rendered
decimal / double	-3.5	new java.math.BigDecimal("-3.5")
long	2	2L
integer / relation FK	2	2
string	2, true	"2", "true"
not resolvable	2	2 (as before)

A constant the column cannot hold in any spelling - a text into a decimal, a fraction into a whole-number column, a number into a boolean, any constant into a date/time - is refused at parse by typeMismatch, naming the column and the reason, rather than shipped as a literal of the wrong type. A copy (item.<Field> / source.<Field> / null) is not type-checked: the two columns' types are the author's business. No module in the fleet authors posts: today, so nothing in the field is affected by the new refusals.

3. A fourth copy of the same escape loop

PostSetSupport.escape was byte-for-byte JavaLiterals.escape (ide-template, package-private), and GlueIntentGenerator.javaLiteral was a third, weaker vocabulary for the same job - a backslash-then-quote pass that survives a quote but not a newline, which closes the literal too. JavaLiterals is now public (engine-intent already depends on ide-template), both call sites use it, and its javadoc says it is THE escape so a fifth copy does not appear. Pattern noted in #7241.

Verified

• mvn -pl components/engine/engine-intent,components/ide/ide-template test: 1212 and 143 green.
• GluePostsTest (8 cases): the typed rendering per TargetType, the type read off a parsed model, the four type refusals, and the quoted remedy driven through IntentParser.parse.
• IntentEngineIT#posts_writes_every_row_of_one_source_event_in_one_transaction: the fixture sets a decimal, a long, an integer and a text constant; the generated post must carry row.Factor = new java.math.BigDecimal("-1.5");, row.Sequence = 7L;, row.Direction = 2;, row.Ledger = "issued";. Green.
• IntentPostsAtomicityIT: its fixture now sets a decimal (-1.5) and a long (7) constant, so the whole generate → publish → compile → post → read-back run is the proof they compile - the bare literals would have produced no handler and no rows. Green.

Not verified: no other IT or template branch renders posts: set: (grep), and no .intent in the module fleet authors posts: at all, so there is nothing else to regenerate.

Fixes #7287

🤖 Generated with Claude Code