intent: a cross-model schedules[].where status NAME is still silently unresolved (#7251 follow-up)

[delchev]

Describe the bug

PR #7269 (#7251) resolves a seeded status NAME in schedules[].where for a same-model source and skips a cross-model one on purpose:

// parser/StatusSymbolResolver.java:341-343
if (schedule == null || text(schedule, "model") != null) {
    continue;
}

The issue asked that "a cross-model source keeps id-only and says so, like the header-level rule". The skip is silent on both ends: IntentParser.validateWhereStatusValue returns early when source == null (:2052-2054, and validateSchedules sets source = null for every cross-model schedule, :909-923), and the generation-time check the javadoc defers to validates only field existence (GlueIntentGenerator.java:4302-4306, isMissing(sourceProps, condition.getField())), never the value. So

schedules:
  - { name: dunning, entity: SalesInvoice, model: invoices, cron: ..., where: [{ field: Status, op: eq, value: OVERDUE }] }

parses, generates (ScheduleSupport.valueToJava quotes any non-number, :216-226) and produces .eq("Status", "OVERDUE") against an integer FK column - matches nothing, forever, with no diagnostic. That is the #7251 failure, one model: key away.

The sibling cross-model sites DO say so: rewritePostings (StatusSymbolResolver.java:279) and rewriteGenerates (:301) build a Target(source, model) and resolveSymbol reports "belongs to model [x] ... must be referenced by its numeric seed id" (:626-628). The PR body's reason ("nothing identifiable to say so about" - which condition is the status is unknowable at parse) only holds at parse: at generation the owner's .model is in hand (sourceTarget.propertyNames() with types), and a non-numeric literal against the owner's function: EntityStatus FK column can be refused there with the same sentence.

Expected

A cross-model schedules[].where condition whose field is the owner's status relation and whose value is not an integer is refused at Generate, naming the model and the id-only rule; the guide's "keeps the numeric seed id" sentence describes what happens to a name too.

[delchev]

PR #7300 (#7225) fixes the same shape for a cross-model create-from's items: where:: the generator resolves the cross-model source via CrossModelSupport.resolve(...) and refuses a non-numeric value on the condition whose field is TargetInfo.statusProperty() (the owner .model's DOCUMENT_STATUS property). GlueIntentGenerator.crossModelItemStatusName / isSeedId are the pieces; the schedule branch around buildSchedules (sourceCrossModel) can apply the same check to schedule.getWhere().