initializeCommand: HostExecutor wiring on EngineOptions

[bilby91]

initializeCommand runs on the host per spec, not in the container. Today runInitialize returns a stub error:

return &LifecycleError{
    Phase: config.LifecycleInitialize,
    Cause: fmt.Errorf("initializeCommand not supported in v1 (host-side execution requires explicit caller wiring)"),
}

The reasoning was security: devcontainer.json can declare arbitrary host commands, so we shouldn't shell out from inside the engine without an explicit opt-in.

Plan

Add to EngineOptions:

// HostExecutor optionally executes initializeCommand on the host.
// Required when UpOptions.RunInitializeCommand is true; nil leaves the
// phase a no-op error. Library does NOT shell out by default —
// callers wire whatever sandboxing / approval flow they need.
HostExecutor func(ctx context.Context, cmd Command) error

runInitialize calls e.opts.HostExecutor(ctx, *cmd.Single) when set; returns the v1 stub error otherwise.

Acceptance

• HostExecutor field exposed
• Unit test: HostExecutor is invoked when set, error returned when nil
• Documented opt-in in package doc + design/runtime.md §1