Fix Join task resolution when joinOn references a Switch/Decision task

## Bug Description

When a Join task's \`joinOn\` list contains a reference to a container task (like Switch), the Join waits on the container itself rather than its terminal child task. This causes Fork/Join workflows with nested Switch tasks to fail:

```
[Fork]
/ \
v v
[SimpleTask] [Switch] --caseX--> [InnerTask]
\ /
v v
[Join]
```

The Join waits on \`[branch1_simple, branch2_switch]\` but should resolve \`branch2_switch\` → \`branch2_simple_inside_switch\`.

## Proposed Solution

Introduce a polymorphic \`getTerminalTaskRef()\` method in \`WorkflowSystemTask\`:

- **Base implementation**: returns the task itself
- **Switch override**: resolves to the terminal task within the selected case branch, supporting recursive nesting
- **Join**: uses \`SystemTaskRegistry\` to polymorphically resolve container tasks in \`joinOn\`

This follows the Open-Closed Principle — new container task types just implement \`getTerminalTaskRef()\`.

## Affected Files

- \`core/src/main/java/com/netflix/conductor/core/execution/tasks/WorkflowSystemTask.java\`
- \`core/src/main/java/com/netflix/conductor/core/execution/tasks/Switch.java\`
- \`core/src/main/java/com/netflix/conductor/core/execution/tasks/Join.java\`

## Prior Art

Community PR #718 by @v1r3n (maintainer) implemented this with comprehensive tests and integration tests (1191 additions).

Read WorkflowSystemTask.java, Switch.java, and Join.java first, then review the comprehensive tests and integration tests from prior art PR #718. Trace how joinOn references are resolved for nested Switch branches. Done means a Join resolves each referenced container to its selected terminal child, including recursive nesting, without regressing ordinary tasks.

Written by the indexing model from the issue text.