feat(intent): generates.items supports a non-composition FK-referencing source item + decimal item defaults

[delchev]

Fixes #6366.

Problem

An item create-from (generates with an items: block) assumed the item source is a composition child living in the source document's perspective package, and rendered numeric item defaults: as bare literals. That breaks when the item source is a separate primary entity referencing the source document by FK — an aggregate document whose per-line detail is its own entity (e.g. a period-aggregate document whose per-member detail rows are a standalone entity). The emitted code then references the item type in the wrong package (cannot find symbol), and a decimal item default like quantity: 1 renders as item.Quantity = 1; → incompatible types: int cannot be converted to java.math.BigDecimal.

Fix

• The source item's package now resolves from its own perspective (fromItemPerspective), not the source document's. For a composition-child item this equals fromPerspective, so existing create-froms are byte-identical. The template qualifies srcItem with it.
• Item defaults use childAssignments (numeric → BigDecimal), the same path the scheduled-children generation already uses, so a decimal line column gets a compilable value.

Three layers: GlueIntentGenerator (glue), generateUtils.js (sanitized package var), Generate.java.template (uses it).

Test

GlueGeneratesTest.nonCompositionSourceItemResolvesItsOwnPackageAndDecimalDefaults asserts the item resolves its own perspective (distinct from the source document's) and the decimal default renders as BigDecimal. Existing generates tests unchanged (composition-child path is a no-op).

Follow-up: extend IntentEmissionCoverageIT with a non-composition item-source fixture asserting the emitted controller compiles and serves (the outermost layer); tracked in #6366.

🤖 Generated with Claude Code