feat(intent): month/week fields first-class on every surface - type-aware now defaults, formatted labels, my/partner pickers

[delchev]

Adopting a `type: month` field (the YYYY-MM string + month-picker widget) on a real reporting-period column surfaced three gaps that together made the type unusable on a document families' period columns:

1. `defaults: : now` emits code that cannot compile against a month/week target

A schedules/generates default rendered `java.time.LocalDate.now()` unconditionally. A month/week field is a plain `String` on the generated entity (VARCHAR at the JDBC level), so the emitted job fails javac - and since client Java compiles as one all-or-nothing batch, one such default takes every module's beans down.

`now` is now rendered in the TARGET field's own shape:

• `month` -> `java.time.YearMonth.now().toString()` (YYYY-MM)
• `week` -> the YYYY-Www ISO-week string
• anything else -> `LocalDate.now()` (unchanged)

The target field's logical type is resolved from the local intent for same-model targets, and from the owner model's widget types for cross-model ones: `CrossModelSupport.TargetInfo` gains `propertyWidgets` (name -> widgetType), because month/week are indistinguishable from any other VARCHAR at the JDBC level - the `.model` widget type is the only cross-model carrier of the logical type.

2. A `|format` label token degrades a month value to the raw string

`formatLabelValue` only formatted `TemporalAccessor` values, so `label: "{period|yyyy MMMM}"` stored `2026-07` instead of `2026 July`. The generated repository now parses a `YYYY-MM` string back to a `YearMonth` when a pattern is present - fail-soft: a non-month value, or a pattern demanding fields a month lacks (`dd`), keeps the raw string.

3. The my/partner surfaces render a month field as a plain text input

The manage form and document templates had MONTH/WEEK branches; the four my/partner form and document templates did not, so a month field degraded to a bare text input on exactly the surfaces a period-carrying personal record renders on. All four now emit the same `x-h-month-picker` / `x-h-week-picker` blocks the power form does.

Coverage

• `IntentEmissionCoverageIT`: the Claim fixture gains a month `period` (schedule default `Period: now`, label `{period|yyyy MMMM}`); asserts the YearMonth job emission, the month picker on the power AND my forms, the `YearMonth.parse` label branch, and at runtime a created record's `Name` reading `... 2026 July` (ran green locally: 1/1).
• `GlueSchedulesTest`: the month/week/date `now` shapes (engine-intent suite green: 301/301).
• Assistant guide updated (defaults `now` shape at both call sites, label month formatting).

Additionally verified on an isolated instance with a two-model workspace (a consumer module's schedule generating into another model's month field): the emitted job carries the YearMonth shape resolved through the owner `.model`, the full client-Java batch compiles, and a POSTed record's computed label formats the month.

🤖 Generated with Claude Code