Centralize Palace runtime initialization

[hughcars]

Motivation

palace::Run currently relies on several runtime preconditions that are set up by callers. PR #735 exposed how fragile this is: the Catch2 test driver needed to mirror pieces of palace/main.cpp, including the STRUMPACK/PtScotch/SLATE MPI_THREAD_MULTIPLE requirement, plus device, HYPRE, SLEPc/PETSc, libCEED, and OpenMP initialization/finalization details.

Keeping that contract as a list in driver.hpp is easy to drift and hard for new test drivers or tools to use correctly.

Proposal

Introduce a small runtime initialization/lifecycle abstraction (name TBD, e.g. palace::Runtime, palace::Initialize, or palace::RuntimeSession) used by both the application driver and test drivers.

It should centralize the ordering and ownership of:

• MPI thread-level selection before Mpi::Init, including the STRUMPACK + PtScotch/SLATE MPI_THREAD_MULTIPLE case.
• OpenMP thread configuration.
• MFEM device selection and GPU assignment.
• HYPRE initialization.
• SLEPc/PETSc initialization/finalization when enabled.
• libCEED initialization/finalization.
• Any timer/resource-reporting setup that is part of process/runtime lifecycle rather than a single solve.

palace::Run should then only require an initialized runtime and focus on a single solve.

Acceptance criteria

• palace/main.cpp and test/unit/main.cpp use the same initialization lifecycle path.
• The STRUMPACK + OpenMP MPI thread-level requirement remains covered in both the executable and unit-test harness.
• Existing CLI behavior is preserved.
• Unit tests and regression tests continue to pass.
• The palace::Run precondition comments shrink to a simple initialized-runtime contract rather than a hand-maintained checklist.