Feature: C-path expectation mocking for the CUnit variant (evaluate CMock vs FFF)

[Ulrond]

Problem/Opportunity

The C++/GTest variant now has GoogleMock support (#253) for mocking C++ interfaces, but the C / CUnit variant has no expectation-based mocking. Today the only C-path substitution mechanism is BUILD_WEAK_STUBS_SRC (link-time weak stubs), which lets a stub replace a strong symbol but offers no call expectations, argument matchers, return-value programming, or call-count verification. HAL unit tests written in C therefore cannot assert how their dependencies are called.

Proposed Solution

Add expectation-based mocking to the C path, symmetric with the gmock wrap. Because the choice materially affects tooling and integration, the ticket is to evaluate and select, then implement:

• CMock (ThrowTheSwitch) — generates mock C functions from a header (aligns with the autogeneration theme of Feature: Autogenerate gmock mocks + CPP/gtest test skeletons from interface headers #254), but is Ruby-based and designed for Unity, so its generated mocks would need routing through CUnit rather than Unity assertions.
• FFF (Fake Function Framework) — header-only, no codegen, no Ruby, framework-agnostic; integrates cleanly with CUnit but does not auto-generate from headers.
• CMocka — full framework (would overlap CUnit) — likely out of scope, note for completeness.

Deliver, for the chosen framework:

• Build/tooling wiring for the C variant.
• UT_MOCK_* C-path wrappers consistent with the C++ ut_gmock.h naming, so tests read similarly across variants.
• A worked example mocking a C interface, plus docs (AGENTS.md/README).

Acceptance Criteria

• A C/CUnit test can define a mock/fake of a C dependency, set call expectations (args/return/count), and have unmet expectations fail the run.
• Failures are reported through ut-core/CUnit, not a second framework's assertion path.
• Decision (CMock vs FFF) recorded with rationale; no unmet build dependency silently required.

Additional Notes

• C-path counterpart to Feature: Wrap GoogleMock (gmock) in ut-core with UT_ mocking macros + examples #253 (gmock wrap). If CMock is chosen, header-driven mock generation could extend Feature: Autogenerate gmock mocks + CPP/gtest test skeletons from interface headers #254.