A posting's rule column is required where the line that reads it books

[nedelcho-delchev-tues]

Fixes #7649

usedRuleColumns collected every rule(<column>) reference of every item row, and the generated handler checked all of them before deriving anything. So a column read by a single when:-guarded line gated the whole posting. The day an optional line was added — a promotion account on the few invoices that carry one — every document of that type stopped posting on every tenant whose rule row predated the new column, including the ones the line does not apply to. Nothing threw and nothing was logged, so the documents just accumulated on the unposted worklist.

The gate now follows the line that reads the column.

• An unguarded row books on every document of its type, so a null column of its own genuinely stops the posting. Those columns keep the up-front check.
• A guarded row's columns ride on the row (ruleColumns) and are checked inside that row's own guard, where the line actually books. The classifier ternaries of rule(by: ...) split the same way (ruleCaseGuards on the row, conditionalRuleGuards keeping only the unguarded rows').

Every skip path now says so. No matching rule row, a null column, an undetermined account — each WARNs naming the rule entity, the match value and the source key. The handler fires only on the event, so a silent skip left nothing anywhere to explain the gap.

The item rows are derived into a list before anything is written, so the early return a missing column takes still happens before the first write.

Covered by GluePostingsTest (the existing fixture's third row is when: "Vat != 0", so its VAT account moves off usedRuleColumns and onto the row — a rule row without one now posts a zero-rated invoice) and GlueGeneratorTest.aGuardedRowsRuleCaseCellsGuardThatRowAlone. Both suites green: 1479 in engine-intent, 217 in ide-template.