Respect retention configuration when terminating pre-flight invocations

[tillrohrmann]

Problem

Killing or cancelling an invocation in the Inboxed or Scheduled state immediately removes the invocation status and any initialized journal, regardless of its configured completion and journal retention.

Both termination flavors route pre-flight invocations through terminate_inboxed_invocation or terminate_scheduled_invocation:

These helpers currently:

• Finish VQueue entries with Duration::ZERO.
• Unconditionally delete the invocation status.
• Unconditionally delete any initialized journal.

The pre-flight metadata already contains completion_retention_duration and journal_retention_duration, but the termination paths discard those fields:

Consequently, a terminated pre-flight invocation appears never to have existed. Its termination result cannot be queried or returned for deduplication, even when the invocation is an idempotent request or workflow whose completion should have been retained.

This differs from terminating an invocation after it has started. The in-flight completion path:

• Stores InvocationStatus::Completed when completion retention is nonzero.
• Deletes the status only when completion retention is zero.
• Deletes the journal only when journal retention is zero.
• Retains the corresponding finished VQueue entry for the completion-retention duration.

Expected Behavior (to be discussed)

Terminating an Inboxed or Scheduled invocation should follow the same retention rules as terminating an in-flight invocation:

Completion retention	Journal retention	Expected result
Zero	Zero	Transition to Free and delete the journal
Nonzero	Zero	Transition to Completed, retain the termination result, and delete the journal
Nonzero	Nonzero	Transition to Completed and retain both the termination result and journal

The completed result should contain the appropriate killed or cancelled failure.

The completion timestamp should be the termination command's replicated record timestamp so that cleanup and replay remain deterministic.

Inbox entries and scheduled timers should still be removed immediately.

[tillrohrmann]

Backwards Compatibility

Changing the interpretation of existing TerminateInvocation records unconditionally could produce different state when replayed by different server versions.

A possible compatibility mechanism is a new persisted, one-way PartitionFeatureChange activated through VersionBarrierCommand.

Alternatively, one could extend the termination command with a new field that signals whether the invocation should be immediately purged or not.