fix: always return variables context in getResultContext

[barmac]

Proposed Changes

This changes the variables tracking so that we don't fail when expression cannot be parsed at all (#57). For a long broken expression, we entered ContextTracker#reduce and collected "variables" via first call. But for an immediately broken expression, we returned null which broke the mechanism. Perhaps we could have avoided this problem with proper type checking.

Try out via:

npx @bpmn-io/sr camunda/camunda-modeler -l bpmn-io/variable-resolver#additional-pr

Checklist

To ensure you provided everything we need to look at your PR:

• Brief textual description of the changes present
• Visual demo attached
• Steps to try out present, i.e. using the @bpmn-io/sr tool
• Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

[nikku]

@barmac How does the problem manifest? I'd like to verify the fix E2E. I.e. would this fail previously?

---

Desktop Modeler v5.39.0

Preview environment

Spun up using npx @bpmn-io/sr bpmn-io/bpmn-js-properties-panel -l bpmn-io/variable-resolver#additional-pr.

➡️ I see that target is properly suggested now, despite the unparseable FEEL expression.

[barmac]

@barmac How does the problem manifest? I'd like to verify the fix E2E. I.e. would this fail previously?

In the current nightly, you get an unhandled error once you create an expression broken before first variable name, e.g. via ai agent connector:

Screen.Recording.2025-09-30.at.09.34.05.mov

[barmac]

I've added sr command in the top comment: #58 (comment)

[nikku]

I can confirm that the reported bug is fixed, and that test cases are present.