[Feature] Agentic subprocess enhancements: user prompt, fragment-aware tool completion, LLM-supplied inputs, and rich tool results

### Description of Problem

Four enhancements to build on the agentic ad-hoc subprocess orchestrator:

**1 — Configurable user prompt.** https://github.com/finos/fluxnova-plugins/issues/59, https://github.com/finos/fluxnova-modeler-plugins/issues/23
When I model an agentic subprocess, I want to define the agent's task in the BPMN model, so each agent starts with a goal specific to my process. Today `systemPrompt` is configurable and the first user message uses a built-in default — making it configurable too completes the prompt story.

**2 — Fragment-aware tool completion.** https://github.com/finos/fluxnova-plugins/issues/60
When a startable activity has outgoing sequence flows, I want the orchestrator to treat the whole chain as one unit of work, so the LLM resumes only when the chain finishes and subprocess completion always lands cleanly. Today completion is signaled when the startable activity ends; extending this to cover downstream activities lets modelers compose multi-step tools with sequence flows. The engine already tracks chains correctly — this update aligns the orchestrator's signal with it.

**3 — LLM-supplied activity inputs.** https://github.com/finos/fluxnova-plugins/issues/61
When the LLM picks a tool, I want it to provide input values, so activities can run with call-specific data. Today tools read from existing process variables; letting the LLM supply values as well opens up a much wider range of tool designs.

**4 — Rich tool results.** https://github.com/finos/fluxnova-plugins/issues/62
When a tool finishes, I want the LLM to see what it produced, so it can reason about the outcome and choose its next step well. Today the tool response carries a simple ok/error status; returning the tool's actual outputs makes each turn far more informed.

### Potential Solutions

### 1. `userPrompt` on `agent:config`

Add a `userPrompt` attribute next to `systemPrompt`. Support `${...}` expressions so the prompt can be instance-specific. Fall back to the current default when empty. Add a matching field in the modeler plugin.

### 2. Fragment-aware tool completion (plugin-only)

Hook the point where the engine itself decides a child execution has fully ended — after the whole chain, not after the first activity. The engine already exposes this to plugins (a behavior subclass installed at parse time), so no engine changes are needed, and gateways, conditions, and loops inside a chain work automatically.

As part of this, add a parse-time check that agent subprocesses disable engine auto-complete, so the two completion mechanisms stay coordinated.

### 3. LLM-supplied activity inputs

Stay with the BPMN pattern: values flow in through input mappings, out through output mappings. The one addition is a way to say "the LLM supplies this value" — a new `agent:arg` expression function:

```xml
${agent:arg('city', 'City to get weather for')}
```

Each tool's input schema is built by scanning its input mappings for `agent:arg(...)`. The LLM's values are scoped to the single tool call, so parallel calls stay independent, and process state still changes only through output mappings.

- One source of truth: the mapping declares the name, the hint, and the wiring.
- Trade-off: a custom EL function that other tooling won't recognize.

### 4. Rich tool results

Mirror item 3 on the output side: when a tool's chain completes, build the tool response from the variables its output mappings wrote. Those mappings are already parsed today (they feed the tool descriptions), so the same declarations define what flows back to the LLM — no new modeling constructs needed. On failure, include the actual error message instead of a bare error flag.

Start by tracing the agent:config handling, the engine child-execution completion hook, and the input/output mappings used to build tool schemas and results. Verify how userPrompt expressions and agent:arg(...) would be scoped per call, then confirm completion, supplied inputs, rich outputs, and the existing default prompt across the four requested enhancements.

Written by the indexing model from the issue text.