riscv: add multikernel architecture skeleton

[nickolaev]

Summary

• enable the multikernel architecture contract for rv64 SBI kernels with kexec-file and CPU hotplug
• translate logical CPUs through the sparse RISC-V hart-ID maps and reject INVALID_HARTID before lookup
• reserve the control block for the spawn context, generated DTB, and fence.i entry stub
• declare the generic contiguous-allocation and memory-hotplug dependencies required by the multikernel core
• add compile-only implementations of every architecture interface hook
• gate CPU pool entry behind ARCH_HAS_MK_POOL_STATE, selected by x86 but intentionally absent from the RISC-V skeleton

Scope

This is intentionally the compile/link skeleton from issue #22. Runtime SBI HSM spawn and parking, the I-cache entry stub, Image loading, DTB filtering, and the cross-kernel doorbell remain in their follow-up issues.

Unsupported ownership operations fail explicitly: every RISC-V repark hook returns -EOPNOTSUPP, and the generic CPU-removal path rejects architectures without pool-state support before it marks or offlines a CPU.

Validation

• clean rv64 Kconfig negative test: MULTIKERNEL cannot remain enabled while CONTIG_ALLOC, MEMORY_HOTPLUG, or MEMORY_HOTREMOVE is absent
• dependency-complete rv64 configuration resolves CONFIG_MULTIKERNEL=y with ARCH_HAS_MK_POOL_STATE disabled
• GCC 15.2 rv64 cross-build: arch/riscv/boot/Image is ready
• x86 configuration resolves CONFIG_ARCH_HAS_MK_POOL_STATE=y and compiles kernel/multikernel/hotplug.o
• focused W=1 builds for the RISC-V stubs and generic hotplug path on rv64 and x86
• git whitespace checks
• checkpatch: 0 errors, warnings, or checks for the review-fix diff

Closes #22.

[congwang-mk]

Two intent-vs-behavior mismatches in the RISC-V stubs, inline below.

[congwang-mk]

mk_repark_instance_to_host() and mk_repark_cpu_to_instance() return 0 (success) while mk_arch_spawn_instance() and mk_arch_confirm_parked() return -EOPNOTSUPP. A generic-core caller that reparks a CPU will believe ownership transferred and proceed to hand the hart to/from an instance that was never actually parked. Returning -EOPNOTSUPP here matches the header comment ("fail explicitly instead of pretending that a hart moved").

[nickolaev]

Fixed in dcc1932: all three RISC-V repark hooks now return -EOPNOTSUPP, so the generic core cannot treat an unsupported ownership transfer as successful.

[congwang-mk]

mk_enter_pool_state() panics the host. If the generic core reaches this on a CPU-pool path (it is the __noreturn hook other arches use when offlining a CPU into the pool), an unsupported operation takes down the whole host instead of failing the offline request. Same intent-vs-behavior mismatch: better to reject the pool transition earlier (e.g. from mk_arch_register_cpu() or a capability check) so this hook is never reached.

[nickolaev]

Fixed in dcc1932 with a temporary ARCH_HAS_MK_POOL_STATE capability. x86 enables it; the RISC-V skeleton leaves it disabled. mk_do_cpu_remove() checks the capability before marking or offlining the CPU and returns -EOPNOTSUPP, so generic pool and hotplug removal paths cannot reach mk_enter_pool_state() on RISC-V. The rv64 Image build and an x86 focused hotplug build both pass.