[Feature]: Patina should allocate and manage its own stack.

Feature Overview

The present implementation of patina uses the stack constructed for it by whatever agent loaded the patina core. The location of the stack thus allocated is reported to the core as part of the HOB list.

Once Patina is up and running, it should allocate its own stack (with desirable properties like configurable size and guard pages, etc.) and switch to that stack instead of the one provided by the loader.

Solution Overview

1. Patina core initialization through init_memory would continue to use the stack provided by the loader.
2. Once memory services are available in Patina, it should allocate and initialize a new stack and switch to using that stack for the rest of the UEFI lifetime.
3. The new stack should have desirable security properties (guard page to detect stack overrun, NX mapping).

Some additional desirable elements:

1. We should try and use an existing crate (e.g. PSM https://crates.io/crates/psm, or perhaps extending our current corosensei fork).
2. We should try to converge our stack construction so that it is architecturally consistent between construction of the patina core stack and construction of individual stacks for module execution.

Alternatives Considered

Do nothing: present core works well on the loader stack for the most part. But drawbacks include having portions of security story bound up in loader design choices (for example, loader may not add guard page or mark stack as NX).

Urgency

High

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

Marked as high urgency because it may have implications for core API (e.g. start() might need to be divergent) that we should consider sooner rather than later.

Start by tracing Patina core initialization through init_memory and the loader-provided stack, then examine when memory services become available and how start() defines the UEFI lifetime. Compare PSM and the current corosensei fork for stack allocation and switching, including guard-page and NX support. Done means Patina allocates and switches to its own securely configured stack while preserving initialization requirements.