fix: read alert pipelines that carry an if condition

[ysyneu]

Bumps go-flashduty to v0.14.2, which decodes rules[].if and alert_inhibit.source_filters as the flat AND-lists the server actually returns.

Before this, alert pipeline-info / alert pipeline-list failed outright on any integration whose pipeline had an if condition:

json: cannot unmarshal object into Go struct field
AlertPipeline.rules.if of type []FilterCondition

Since pipeline-upsert replaces the whole pipeline and so must be preceded by a read, that made those pipelines unreachable from the CLI entirely.

Cards carried the same wrong shape

• alert.md claimed both fields were OR-of-AND trees. They are flat AND-lists — the nesting belongs to the silence / inhibit / drop / escalation families only.
• alert.md described settings.title / settings.description as <template> without saying what a template is. Now documents the [TPL] prefix, ${label} and {{.Labels.x}} substitution, the bare :: title form, and that description_reset without [TPL] is a silent no-op.
• filters.md listed alert pipeline among the OR-of-AND families; split out with a pointer to the flat shape.

Also from the v0.14.2 bump

• channel unsubscribe-rule-create / -update lose --priority — drop rules have no priority server-side.
• knowledge-pack rows gain duty_version.

Verification

Against a live integration, with a rule carrying an if condition:

• this build writes it, reads it back, and renders it correctly;
• the previously released build fails to read the same row with the exact error above.

make fmt test green; make check-cards green.