Switch from MallocAllocator to Zephyr k_malloc allocator

[yudataguy]

Description

Replace Fw::MallocAllocator (libc malloc) with a custom ZephyrKmallocAllocator backed by Zephyr's k_malloc/k_free. This ensures heap usage is tracked by the kernel memory pool, giving an accurate picture of runtime RAM consumption. Previously, the build reported ~75% RAM usage but libc malloc allocations were invisible to Zephyr's memory accounting.

Also unifies the separate ComCcsdsSband and ComCcsdsLora allocation namespaces into a single ComCcsds::Allocation namespace, and configures HEAP_MEM_POOL_SIZE=65536 in prj.conf for the Zephyr kernel heap.

Related Issues/Tickets

Closes #313

How Has This Been Tested?

• Unit tests
• Integration tests
• Z Tests
• Manual testing (describe steps)

Screenshots / Recordings (if applicable)

N/A

Checklist

• Written detailed sdd with requirements, channels, ports, commands, telemetry defined and correctly formatted and spelled
• Have written relevant integration tests and have documented them in the sdd
• Have done a code review with
• Have tested this PR on every supported board with correct board definitions

Further Notes / Considerations

[LeStarch]

Another thing, it this should be configured as the default memory allocator using the allocator.

[yudataguy]

Replace the previous Zephyr kmalloc allocator behavior with an alignment-safe implementation for RP2350/M33.

This change fixes ZephyrKmallocAllocator so it only uses k_malloc when the requested alignment is within Zephyr’s documented guarantee, and avoids treating k_malloc as safe for stricter default-alignment requests on 32-bit ARM. The previous behavior could return under-aligned memory during boot and plausibly hard-fault on RP2350/M33.

Once approved, do not merged yet, since it needs to update the fprime-zephyr repo first

[ineskhou]

Great PR! Learned a lot by looking though it, and we can see a 15% increase in proper RAM allocation. Super awesome! And the consolidated Comcsds bloc is much cleaner as well so thank you for cleaning up the subtopologies ensuring when we add coms subtoplotogies they are all good

I have two quick pieces of feedback, more of suggestions than anything. Even if we deem them important, we can always do them later in another PR

1. I would want to look at our, zephyr submodule we are some commits behind main, including some commits from Starch that have to do with Open-Source-Space-Foundation/fprime-zephyr@main...fprime-community:fprime-zephyr:main including the Add send recv PR

2. My understanding is we are covering the allocation in the Com Subtopology bc thats most of our code

Some things we could add to cover more ground:

• We could change the default allocator by overriding this config and add it to project/config
  This I think would only touch the Zephyr allocator. My understanding of this is would help with zephyrs memory allocation at the beginning (see bellow) but I'm not sure. Would be worth trying and seeing if the number changes, because I do think we are probably using more than 75% RAM

Zephyr’s platform config selects Os_Generic_PriorityQueue (lib/fprime-zephyr/cmake/platform/zephyr/Platform/CMakeLists.txt),

In lib/fprime/Os/Generic/PriorityQueue.cpp allocates internal queue storage via

    // Get the memory allocator configured for priority queues
    Fw::MemAllocator& allocator = Fw::MemAllocatorRegistry::getInstance().getAnAllocator(
        Fw::MemoryAllocation::MemoryAllocatorType::OS_GENERIC_PRIORITY_QUEUE);

In lib/fprime/Fw/Types/MemAllocator.cpp, getAnAllocator falls back to the SYSTEM allocator unless registerAllocator is called, which is it not in our code I believe

MemAllocator& MemAllocatorRegistry::getAnAllocator(const MemoryAllocation::MemoryAllocatorType type) {
    // If the allocator is not registered, return the SYSTEM allocator
    if (this->m_allocators[type] == nullptr) {
        return this->getAllocator(MemoryAllocation::MemoryAllocatorType::SYSTEM);
    }
    return *this->m_allocators[type];
}

SYSTEM is constructed from Fw::MemoryAllocation::DefaultMemoryAllocatorType in lib/fprime/default/config/MemoryAllocation.hpp which currently defaults to Fw::MallocAllocator, which is why I think overrride the prj.conf could be worthwhile!

3. Lastly This is super awesome but I think it would benefit for clearer documentation. If we ever add another non-comms subtopology, for example, if we want to add data products (probably not in the shoert tmer, but long term seems likley) we want whoeever is mainininting it to remember that each subtopology needs to also have X YZ. Would be good to have a section explaining t in our docs somewhere so they are easy to ref