Evaluate parallel setup execution for independent artifacts

[codeforester]

Problem

Base has parallelized independent check probes, but setup still needs a deliberate evaluation before any concurrent execution is introduced. Fresh-machine setup can be slow, yet setup commands often touch shared package managers, shared virtual environments, logs, and user-visible progress output.

Desired outcome

Decide whether Base should parallelize any part of basectl setup, and if so define the safe first slice with explicit ordering, logging, dry-run, and failure semantics.

Scope

• Measure or characterize current setup bottlenecks across Base-managed artifact types.
• Identify setup operations that are truly independent and safe to run concurrently.
• Define how progress output, logs, exit status, cancellation, and partial failures should work.
• Preserve deterministic dry-run behavior and inspectable setup plans.
• Compare against the existing parallel check-probe work so setup does not inherit the wrong concurrency model.

Non-goals

• Do not blindly parallelize all artifact installation.
• Do not run package managers concurrently when they share locks, caches, or mutable state unsafely.
• Do not weaken setup idempotency or diagnostic clarity for speed.

Acceptance criteria

• A design note or implementation issue records whether setup parallelism is worth shipping.
• If worth shipping, the first implementation slice names the artifact classes or phases that can run concurrently.
• The design covers text output, logs, JSON or structured status if applicable, dry-run, failure handling, and cancellation.