fix: let callers send meaningful zero values on request fields

[ysyneu]

What

v0.12.1 fixed follow_preference, a request field whose zero value carries meaning but which was generated as a plain bool with omitempty — so Go dropped false and the server never saw it. A sweep for the same shape across the whole spec — join "server models the field as a pointer and branches on nil" against "SDK generates a value scalar with omitempty" — turned up five more, plus a property whose name never matched the server at all.

Fixed

Field	Was	Now
RUMApplicationUpdateRequest.IsPrivate / .NoGeo / .NoIP	bool	*bool
RUMApplicationAlerting.Enabled	bool	*bool
RUMFieldListRequest.IsFacet	bool	*bool
ScheduleNotify.AdvanceInTime	int64	*int64
TemplateCreateRequest / TemplateUpdateRequest / TemplateItem	feishu_app_card_table_enabled	feishu_app_card_v2_table_enabled

• RUM privacy toggles. /rum/application/update applies these three only when present, so they were one-way: an application could be made private, or have geo inference and IP collection switched off, and never switched back through the API.
• RUM alerting. The alerting object is omitzero. A minimal {"enabled": false} override was entirely zero-valued, so the whole key was dropped and alerting stayed on unless the caller happened to re-send unrelated fields. A pointer keeps the container on the wire.
• is_facet. Absent means "every field", true means "facet fields", false means "non-facet fields" — that last mode was unreachable. The description said the opposite and is corrected.
• advance_in_time. 0 means "notify exactly at the shift start"; absent disables advance notification entirely. Only the second was reachable.
• Template property name. The server binds and stores feishu_app_card_v2_table_enabled. The spec spelled it without v2_, and unknown JSON keys are silently discarded, so no value the SDK sent for this property ever reached the server, in either direction, on either create or update — and the response schema misnamed it too.

Source fix lands in the OpenAPI spec (flashcatcloud/flashduty-docs#263); openapi/ is re-synced and models_gen.go regenerated. No hand-edits to generated code, and no generator changes were needed — the existing nullable-request-scalar rule produces the pointers.

Compatibility

Source-breaking for callers that set any of the fields above. Wrap literals with the flashduty.Bool / flashduty.Int64 helpers, and rename FeishuAppCardTableEnabled to FeishuAppCardV2TableEnabled:

-  IsPrivate: false,
+  IsPrivate: flashduty.Bool(false),

Two notes on blast radius:

• RUMApplicationAlerting is one schema shared by the create request, the update request and the application response, so RUMApplicationItem.Alerting.Enabled also becomes *bool. Read paths need a nil check. Splitting the schema to avoid this was rejected as more churn than the fix is worth.
• Create-side fields are deliberately untouched: RUMApplicationCreateRequest's three privacy booleans stay non-nullable, because a create has no prior state for an absent key to preserve.

Validation

• make check — gofmt/gci clean, golangci-lint 0 issues, go test -race ./... green, build OK.
• New wire tests: seven cases asserting each field serialises its zero value ("is_private":false, "advance_in_time":0, "alerting":{"enabled":false}, …), and three asserting a nil pointer stays off the wire while sibling fields still serialise.