Investigation: Is inner_plan / plan stub pattern correctly implemented

`bps.mv(..., group="initial_move")` never waited on
`bps.mv `is called with a group keyword in demo_spectroscopy but bps.wait("initial_move") is never called. Dependent on a previous bug from the time taken to move from current position to start position being greater than 10s.

inner_plan nested closure pattern hides logic and prevents isolation testing
The use of `@attach_data_session_metadata_decorator(), @bpp.run_decorator, and @bpp.stage_decorator on a nested inner_plan()` is unusual. The same effect can be achieved with `bpp.run_wrapper / bpp.stage_wrapper` inline in the generator, which is more idiomatic and testable.

Investigation questions:

- Is bps.mv with a group kwarg doing what the author intended? Does the group need an explicit wait?
- Is the inner_plan closure the recommended pattern, or does using bpp.*_wrapper inline better match Bluesky idioms and allow inner_plan logic to be unit-tested independently?
- Review the Bluesky plan stubs documentation and the existing usage in dodal as a reference implementation.

Start with the demo_spectroscopy plan and inspect the bps.mv(..., group="initial_move") call alongside whether bps.wait("initial_move") is needed. Read the Bluesky plan stubs documentation and compare existing usage in dodal; done means deciding the intended group/wait behavior and whether the nested inner_plan or inline bpp.*_wrapper pattern should be used.

Written by the indexing model from the issue text.