GCC linking fails due to incorrect `libgcc` link order

## Description

We are encountering linker failures on AArch64 builds caused by unresolved outlined atomic helper symbols such as:
```bash
__aarch64_ldadd4_acq_rel
__aarch64_cas2_acq_rel
__aarch64_swp4_acq_rel
```

These symbols are emitted by GCC when compiling with outlined atomics (default on AArch64) and are expected to be resolved from `libgcc`.

We verified that the toolchain-provided `libgcc.a` does contain these symbols, so the issue is not missing runtime support.

## Root Cause

Root Cause

The problem appears to be **link order / link grouping** when using static libraries:
- The link uses a large number of static archives (`-Wl,-Bstatic`)
- `-nodefaultlibs` is enabled, so runtime libraries must be added explicitly
- `libgcc` is either:
- added too early, or
- not grouped with dependent static libraries

Because of this, the linker does not pull in the required objects from `libgcc.a` when resolving references originating from later static libraries.

This is a standard static linking behavior: **archives are only searched once, left-to-right**.

## Proposed Fix

Ensure that `libgcc` (and related runtime libs) are linked **after all static libraries** that may reference them.
Two valid approaches:

**Option 1** — **Late linkage**
Add at the end of the link command:
```bash
-lgcc
-lgcc_eh
```

**Option 2** — **Link group (more robust for large static graphs)**
```bash
-Wl,--start-group

-lgcc
-lgcc_eh
-Wl,--end-group
```

### Expected Changes ot work products

- [ ] Requirements
- [x] Architecture
- [ ] Safety Analysis
- [ ] Security Analysis
- [ ] Detailed Design
- [ ] Implementation and Testing
- [ ] all

### Impact analysis

NA

### Safety or Security relevance

- [x] none
- [ ] Safety relevant
- [ ] Security relevant

### Expected required ASIL classification

QM

### Expected Implementation Version (Release)

1.0