add registration status timeout to remote trigger config

[ettec]

Required for this change: smartcontractkit/chainlink#20973

[github-actions]

✅ API Diff Results - No breaking changes

---

📄 View full apidiff report

[Copilot]

Pull request overview

Adds a new remote-trigger configuration field to control a “registration status update” timeout, wiring it through the protobuf schema and the capabilities registry client/server config translation layer.

Changes:

• Extend RemoteTriggerConfig (proto + Go struct) with registrationStatusUpdateTimeout / RegistrationStatusUpdateTimeout.
• Serialize/deserialize the new duration field in ConfigForCapability responses (both top-level and per-method remote trigger configs).
• Regenerate protobuf Go bindings to include the new field and accessor.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
pkg/loop/internal/core/services/capability/capabilities_registry.go	Maps the new timeout field between internal capabilities.RemoteTriggerConfig and protobuf RemoteTriggerConfig for both capability-level and method-level configs.
pkg/capabilities/pb/registry.proto	Adds registrationStatusUpdateTimeout to RemoteTriggerConfig message.
pkg/capabilities/pb/registry.pb.go	Generated output reflecting the new proto field and getter.
pkg/capabilities/capabilities.go	Adds the new field to the Go RemoteTriggerConfig and attempts to apply a default for it.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new RegistrationStatusUpdateTimeout field is now serialized into the top-level remote trigger config, but there isn’t a focused test that verifies a non-zero value round-trips through the registry client/server conversion. Add a unit test that sets this field to a non-zero duration and asserts it is preserved after ConfigForCapability.

[Copilot]

The new RegistrationStatusUpdateTimeout field is now serialized for method-level remote trigger configs as well, but there isn’t a test asserting that a non-zero value round-trips correctly for CapabilityMethodConfig entries. Extend existing registry tests to cover a method config with a non-zero timeout and verify it survives encode/decode.

[Copilot]

DefaultRegistrationStatusUpdateTimeout is defined as 0 and ApplyDefaults() assigns it when the field is 0, which is a no-op and makes it unclear whether 0 is meant to be a real default or an “unset/disabled” sentinel. Consider either (a) removing the constant + defaulting block entirely if 0 is the intended default, or (b) setting a non-zero default here (and documenting whether callers can explicitly disable by setting 0).

Suggested change

	if c.RegistrationStatusUpdateTimeout == 0 {
	c.RegistrationStatusUpdateTimeout = DefaultRegistrationStatusUpdateTimeout
	}