Shivam 6143b6a4af Pass deployment state and version state in forceCAN signals (#9100) ...

## What changed?
- WISOTT

## Why?
- Operational readiness. There could be a world where we want to "reset"
a user's workflow state given that these workflows CAN so frequently.

## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)

## Potential risks
- None

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Introduces optional state override when force-continuing-as-new.
> 
> - New proto messages `ForceCANDeploymentSignalArgs` and
`ForceCANVersionSignalArgs` with `override_state` fields; generated
helper/pb code updated
> - Deployment and Version workflows now receive `forceCAN` signals with
args and, if provided, apply `override_state` before continue-as-new
> - Added tests verifying override is honored (e.g., manager identity
and metadata) after continue-as-new
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
1fd847da1c. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

2026-01-28 17:23:54 -05:00

..

message.go-helpers.pb.go

Pass deployment state and version state in forceCAN signals (#9100)

2026-01-28 17:23:54 -05:00

message.pb.go

Pass deployment state and version state in forceCAN signals (#9100)

2026-01-28 17:23:54 -05:00