Define FEO determinism boundaries and add Motion/Energy-oriented time determinism and robustness

### What

## Summary

This issue proposes a focused review and extension of **FEO Determinism and Robustness**.

FEO already provides strong foundation for deterministic intra-application execution. However, for Motion and Energy use cases, e.g. such as torque arbitration, inverter command propagation, vehicle-state estimation, thermal and energy management, determinism must usually extend beyond **local execution order**.

These use-cases need deterministic semantics for:

- Logical time per control cycle
- Data age and validity at consumption
- Queue overload behavior
- Cross-application cause-effect chains
- Fault-time output behavior
- Tracing for integration and debugging.

This issue argues that FEO’s current determinism contract is incomplete for those use-cases. The proposal is not to turn FEO into a large all-purpose distributed scheduler. The proposal is to define FEO’s boundaries clearly and add small, high-leverage contracts that integrate with other components.

> Note: this proposal assumes `feo::com` is being deprecated and replaced by `mw::com`.

---

## Background from current S-CORE specs

FEO is described as a framework for applications, not platform services. It supports data-driven and time-driven applications, mainly in ADAS, with fixed execution order and reprocessing support.

FEO specs state:

- Multiple FEO-based applications can run in parallel
- Communication between different applications is not supported by FEO except via service activities
- Application activities are single-threaded and must not spawn threads/processes
- There is exactly one task chain per application
- Task-chain execution order is defined by dependencies
- Activities are statically mapped to threads/processes
- Fixed mapping is used to reduce jitter and avoid nondeterministic task-chain execution time

## Problem statement

FEO provides deterministic **local execution ordering**, but Motion and Energy domain use-cases require deterministic **cause-effect semantics**.

Today, FEO’s determinism guarantee is mainly about:

```
Within one FEO application:
dependency graph + static mapping + task-chain cycle
```

For Motion/Energy, this is not enough. The relevant chain often looks more like:

```
sensor/state estimation app
-> `mw::com`
-> torque/brake/energy management app
-> `mw::com`
-> actuator-facing service
-> inverter/brake/thermal system
```

At each boundary determinism can degrade, unless timing, validity, queuing, and evidence are explicitly defined.

---

## Why this matters

Motion/Energy use-cases need more than “A runs before B.” They need to know:

```
Did A and B use the same logical cycle time?
Was the data fresh?
Was it from the expected cycle?
Was the queue behavior deterministic under overload?
Was the output behavior deterministic under fault?
Can we prove all of that from traces?
```

Without these contracts, a system can be locally deterministic while still being globally fragile. This proposal should make FEO a stronger participant in system-level determinism.

---

## Gap Analysis Results

| Gap | Current situation | Motion/Energy risk |
|---|---|---|
| FEO determinism boundary | FEO is scoped to one application; cross-app communication is not supported except via service activities | Cross-application cause-effect chains are not covered by FEO’s deterministic order |
| Logical cycle time | Time feature requires common logical time in cause-effect cycles, but FEO does not define an explicit cycle time token | Activities may execute under different time assumptions |
| Data validity | Typed communication alone does not encode freshness, validity, sequence, age, or uncertainty | Stale but well-typed data can drive incorrect control decisions |
| Queue overload | FEO defines runtime-static queue length, but not a complete overload/drop/coalescing contract | Burst behavior can become undeterministic |
| Timing budgets | FEO states time/memory/CPU budget handling is outside FEO | Deterministic ordering exists, but deadline budget enforcement is weak |
| Fault-time output behavior | FEO generally shuts down on critical failures; output safe-state behavior is not formalized | Motion/Energy outputs may need defined degraded or safe values, not only termination |

### Acceptance Criteria (DoD)

New tasks are created with proposals, or just agree to close the ticket.

### How

_No response_