feat(intent): a register lookup can filter the register with a constant predicate

[TIVMOF]

What does this PR do?

Adds an optional where: { <register property>: <literal> } to resolves:, ANDed onto the same Criteria as the match keys.

A resolves: lookup had no way to narrow its register by a constant. Every match: pair binds a register column to a column of the record, so "and only the rows that are still valid" had no form at all — and a register is exactly the kind of table that keeps its corrections:

id	vehicle	driver	validFrom	validTo	status
1	CA1234AB	Petrov	2026-01-01	2026-06-30	CANCELLED
2	CA1234AB	Ivanov	2026-01-01	2026-06-30	ACTIVE

A fine on 2026-03-14 should resolve to Ivanov. Both rows match and both cover the date, so the lookup reported ambiguous, routed to manual handling and logged "multiple matches" — for a register with exactly one valid answer. Every correction ever made earned that, quietly, and it got worse the longer the register lived.

resolves:
  - name: identifyDriver
    event: { onCreate: Fine }
    set: driver
    from: VehicleAssignment
    match: { vehicle: vehicle }
    where: { status: ACTIVE }        # <- new
    between: { start: validFrom, end: validTo, value: violationAt }

Three things are deliberately not a mirror of the relation-level where:

• Multiple pairs are allowed and ANDed. That one is capped at a single pair because it lands in two EDM attributes (widgetOptionsFilterBy / widgetOptionsFilterValue); these become chained Criteria.eq calls, where a second condition costs nothing.
• A status pair may use the seeded name, resolved on the register's nomenclature. The existing StatusSymbolResolver.rewriteResolves resolves against the record's lifecycle, which for a register filter hands back a plausible id from the wrong entity. New rewriteResolveWhere resolves against from:. The tests seed ACTIVE as 2 on the record and 7 on the register precisely so that mistake cannot pass.
• Only that pair is offered to the resolver. Handing an ordinary column like kind: PRIMARY to it would report a perfectly valid string as an unknown status.

Refused rather than guessed: a where pair that repeats a match key. On a column already bound to the record a literal either says the same thing twice or contradicts it into matching nothing, and which one it is depends on data the parser cannot see.

The generated handler names the filter in its javadoc and in its notFound log line, so a filter that is too narrow reads as a filter rather than as missing data.

Also fixes two latent defects in the javaLiteral helper this reuses: a Boolean was quoted into the string "true" (which matches no boolean column), and a backslash was not escaped.

Verification

• engine-intent 762/762; IntentEngineIT 55/55.
• Red-first: all 9 new GlueResolveWhereTest cases fail without the change — including unknown key [where], confirming the closed vocabulary really did reject it.

What issues does this PR fix or reference?

• Fixes resolves: cannot filter the register with a literal predicate - cancelled register rows poison lookups as false ambiguous #6812

Release Notes

An effective-dated register lookup (resolves:) can now narrow its register with a constant filter: where: { status: ACTIVE }. This is what lets a register keep its history — cancelled and superseded rows no longer collide with the valid one and force the lookup to give up as ambiguous. Several conditions may be given and are ANDed; a status may be named by its seeded name rather than its id.

Documentation

intent-assistant-guide.md and components/engine/engine-intent/CLAUDE.md are updated in this PR. No matching docs-repo PR — the intent DSL reference lives in-tree.