fix(connection): build rules in flag order

[leggetter]

--rule-* flags always built rules as deduplicate → transform → filter → delay → retry. Filter, transform and deduplicate run in rules[] order, so --rule-filter-body … --rule-transform-name … silently produced transform → filter on create, update and upsert.

• Rules now follow the position of each rule type's first flag, as AGENTS.md ("Ordered Array Configurations") already specifies
• --rules / --rules-file are unchanged and keep the array as given
• The MCP connections tool's rules description now says order matters
• README note on flag ordering

Behaviour change: anyone passing --rule-filter-* before --rule-transform-* and relying on transform running first will now get filter first. That's the order they wrote, but it is a change.

Implementation

• addConnectionRuleFlags wraps each rule flag's pflag.Value in orderTrackingValue. On Set, it records the flag's rule type in connectionRuleFlags.ruleOrder (first occurrence wins).
• buildConnectionRules builds rules into a map by type, then emits them using ruleOrder followed by defaultRuleOrder. Types with no recorded position, such as when the struct is populated directly in tests, keep the old order.
• Flag help text is unchanged, so there's no reference regeneration.

Tests

• New pkg/cmd/connection_rule_order_test.go:
  • flag order through real cobra parsing (filter/transform both ways, first flag wins, all five types, retry positioned by a non-strategy flag)
  • the struct-literal fallback order
  • create, update and upsert commands each record order
• Confirmed the flag-order tests fail against the previous connection_common.go
• go test ./... passes

Context

A customer's agent saw filter → transform flipped to transform → filter on every connection save. Their trigger was the REST API's pre-2025-07-01 versions, where transformations always run before filters. This CLI bug produces the same symptom. Related: hookdeck/agent-skills#29.

🤖 Generated with Claude Code