fix(dsh-plugin): run profile and recall in parallel on pre-step

[ktz03]

Summary

agent/pre-step in dsh-memory-plugin awaited profileMessage then recallMessage sequentially. That waterfall still runs before dsh-agent-loop appends user/message (#4515), so serial OV work adds avoidable latency to the blank chat window.

Run profile + recall concurrently via Promise.all after next() (ensureState is already single-flight safe).

This is a mitigation inside OpenViking's plugin; a complete UX fix still needs dsh-agent-loop to push user/message before the pre-step waterfall.

Related to #4515

Test plan

• node --test examples/dsh-memory-plugin/index.test.mjs
• With the plugin installed, send a message and confirm recall still injects; wall time of pre-step should drop when both profile and recall would have been slow

[now-ing]

Verified the parallelization is behavior-safe on all three fronts I could check statically:

1. No double-initialization: both entry points call initialize(), but ensureState (runtime.mjs:61-68) already has in-flight promise sharing (if (state.initializing) return state.initializing), so concurrent callers join the same initialization.
2. No data dependency: recallMessage(agent, decision.messages) consumes the decision as-is — it never consumed profile output, so running them concurrently cannot change results.
3. Order stability: [profile, recall].filter(Boolean) preserves the message order downstream listeners expect.

Two notes:

• The change ships with zero test coverage, and the harness exists — index.test.mjs is right there and currently has no case pinning the concurrency. Worth adding one: mock the runtime with a profileMessage that resolves only after recallMessage has been entered (a rendezvous via deferred promise), then assert the pre-step completes and both messages appear. That test reds instantly if this ever regresses back to sequential awaits, and it's ~15 lines.
• Abort semantics shift slightly: the old code's post-profile signal.aborted check meant an abort during profiling skipped the recall network call entirely; now both are already in flight when the check runs, so an aborted step can still pay for one wasted recall request. Given recall results are discarded either way, this is a fine trade for the latency win — just noting the delta is real.

Nice, surgical fix for #4515's waterfall cost.

[ZaynJarvis]

lgtm, thx

[ktz03]

Thanks @now-ing — added a rendezvous-style test on this head:

agent/pre-step runs profile and recall concurrently — profileMessage only resolves after recallMessage has entered. A regression back to sequential awaits fails the gate within 500ms.

Abort-semantics note acknowledged (wasted in-flight recall on abort is an accepted trade for the latency win).