Detect split continuation completion and fence appends

[ccarvalho-eng]

Problem

Durable workflow runtimes can expose a completed result before terminal fencing when attempt_completed and run_continuation_fenced are written in separate storage appends. A crash or competing recovery between those writes can apply ordinary progression or execute duplicate side effects.

Proposed rule

Flag continuation producer paths that can persist attempt_completed and run_continuation_fenced through separate append calls instead of one ordered optimistic-CAS batch.

The rule should recognize the safe shape:

1. one append operation on the same dispatch thread,
2. attempt_completed precedes run_continuation_fenced,
3. the append uses the current expected revision,
4. committed-unknown outcomes are covered by an idempotent replay regression.

Acceptance criteria

• detect direct and helper-mediated split appends in Elixir workflow/runtime code
• avoid findings for one ordered multi-entry append
• report the two append locations and the missing atomic boundary
• recommend a committed-unknown-outcome regression that proves one completion, one fence, and no repeated action execution
• include positive and negative fixtures derived from a generic journal runtime, without coupling the rule to Squidie module names

This opportunity came from the durability work for agentjido/jizoku#401.