fix: stabilize smp_bind_affinity_tc on SMP CI

This change fixes intermittent failures of the `core.smp_bind_affinity`
utest across SMP CI targets. The original failure was a flaky assertion on
unbound threads (`thread_inc[x] != thread_tic[x]` in thread_entry), not
incorrect bind_cpu behavior. CI logs already showed T0 binding worked
(thread_inc[0] == thread_tic[0] == 100) while the not_equal check failed.
The root issue is that unbound-thread CPU placement is platform-dependent
and outside the bind_cpu contract. On dual-core RISC-V/ARMv7 CI, an
unbound thread may legitimately run all iterations on core 0 while T0
delays on the same core, so any assertion requiring cross-core migration
(thread_inc != thread_tic, or core_mask with multiple bits) remains flaky.
This patch narrows the test to what bind_affinity actually verifies: T0
bound to core 0 must always execute on core 0. Unbound threads only add
scheduling pressure; their core_mask is printed for observation but not
asserted.
Changes:
- Sample `rt_hw_cpu_id()` and update counters under `rt_sched_lock` to
  avoid migration skew between counting and CPU sampling.
- Track `thread_core_mask` for diagnostics; assert only T0 binding via
  `thread_inc[0] == thread_tic[0]` and `thread_core_mask[0] == 1`.
- Remove flaky unbound-thread assertions (`thread_inc != thread_tic` and
  multi-core core_mask checks).
- Move T0 assertions to the main test thread after all workers finish.
- Use atomic `finsh_flag`; reset counters and `threads[]` in `utest_tc_init`.
- Spin in worker loops after `run_num` until cleanup deletes them (do not
  return from thread_entry or use `RT_WAITING_FOREVER` with `rt_thread_delay`).
- Guard `rt_thread_delete` in cleanup with non-NULL checks.

Signed-off-by: GuEe-GUI <[email protected]>

0 files changed, 0 insertions, 0 deletions