Covered the SMP suspension teardown and the long byte pool search

[fdesbiens]

Against the merged SMP coverage report — every build configuration instrumented and unioned —
sixty-four lines of common_smp/src were uncovered, 5114 of 5178, 98.76%. Fifty-three of
them are closed here and the report reads 5167 of 5178, 99.79%. The SMP coverage floor
goes from 98 to 99 with it, in the same change so that this PR's own run is the proof the
floor clears.

#666 did this for common/src; this is the SMP half, which it never touched.

The largest gap was one loop, four times, and the reason it was uncovered is not obvious

Thirty-six of the sixty-four are the same nine-line loop in tx_block_pool_delete,
tx_byte_pool_delete, tx_event_flags_delete and tx_queue_delete — the walk that releases
every thread suspended on the object with TX_DELETED.

The suite deletes all four object types after every single test, and that is exactly why the
loop never ran. test_control_cleanup() in the ThreadX suite deletes the application's
objects first and its threads last, so a test that ends with a thread parked on a queue has
that thread walked out of the queue by tx_queue_delete. The SMP suite's cleanup deletes the
threads first, on purpose — it was changed so that no application-owned object is still
referenced when the object loops run, which is what stopped a class of teardown hang. Correct,
and the side effect is that every one of those four deletes now runs against an empty
suspension list. tx_semaphore_delete.c is the one member of the family that was already
covered, because threadx_semaphore_delete_test deletes a busy semaphore deliberately.

Please do not "fix" this by putting the SMP cleanup back the way the ThreadX one is.

threadx_object_delete_suspension_test is the same idea as the semaphore test, for the other
four. Two threads suspend on each object; the control thread waits on the object's own
suspended count through tx_*_info_get rather than on an ordering it cannot guarantee across
four cores, deletes it, and checks both waiters came out with TX_DELETED. Two waiters rather
than one so the loop takes its back edge as well as its body, and every wait is bounded in
ticks so that a suspension which never arrives fails the test instead of hanging it.

Two ports of #666's tests — 14 lines

test	closes
threadx_trace_entry_update_test	tx_block_allocate 123/175/182/319/326, tx_byte_allocate 130/210/217/359/366, tx_thread_system_suspend 504/560, tx_trace_object_register 221
threadx_thread_misaligned_stack_test	tx_thread_create 133

The one substantive change is core confinement. The trace test depends on thread 0 suspending
and thread 1 then releasing what it waits for; on four cores thread 1 gives the block back
before thread 0 has suspended, and the update block behind the suspension is never reached. Both
threads are excluded from cores 1–3. The misaligned stack test needed no such change.

The long byte pool search — 3 of 11

Lines 264/267/270 of tx_byte_pool_search.c are the TX_BYTE_POOL_MULTIPLE_BLOCK_SEARCH
limit — twenty on this port — where a long search drops and retakes protection so it cannot
lock the other cores out for the whole walk. No byte pool in the suite ever had twenty
fragments. threadx_byte_memory_long_search_test fills one with small chunks until it
refuses another and releases every second one, so no free fragment has a free neighbour and the
search cannot merge its way out; the request is larger than any single fragment but smaller
than the pool's theoretical total, which is what makes _tx_byte_pool_search walk rather than
refuse at the door. The layout is asserted rather than assumed — the test checks the fragment
count and checks the probe request really does fail before the workers start, because either
would otherwise turn it into a silent no-op.

The eleven that remain are explained, not skipped

Eight are the delay loop at tx_byte_pool_search.c:283–301, which fires when another
thread claims the pool inside the window the search opens. The Linux SMP port serialises all
four cores on one pthread_mutex, so that window is an unlock immediately followed by a lock
on that mutex, and glibc hands an uncontended mutex straight back to the thread that just
released it. Measured: 180,003 windows across three cores, zero handovers. The shipped test
does 250 searches per worker rather than the sixty thousand that probe used, because the
twenty-block threshold is crossed by the first search and the rest buys nothing. Reaching those
eight needs a port whose cores really are concurrent.

Three are in tx_thread_smp_utilities.c. Line 149 is a range guard placed after the
shift it is meant to guard — ULONG >> priority with priority >= TX_MAX_PRIORITIES — so
reaching it needs a shift by the width of the type. The TX_MAX_PRIORITIES > 32 variant of the
same function, sixty lines above, tests the range first and is written correctly; the fix is
to reorder the check, and that belongs in its own change because it edits the SMP scheduler
and this is a test-only PR apart from the threshold. Lines 1073/1074 are the priority-inheritance
arm of _tx_thread_smp_simple_priority_change, reachable only from _tx_mutex_priority_change
on a raise, and only when the mutex owner is genuinely executing on another core as the waiter
suspends. Three shapes were tried and none produced that on this port.

Measurements

Two runs before and two after, every .gcda deleted between runs, 570 of 570 tests passing
each time:

	lines	rate	branches
before, run 1 and run 2	5114 / 5178	98.76%	2768 / 3548
after, run 1	5167 / 5178	99.79%	2821 / 3548
after, run 2	5167 / 5178	99.79%	2823 / 3548

The suite gains four tests, 110 to 114 per configuration, and about a second per configuration
of wall clock.

A floor of 99 needs 5127, so the ratchet lands with forty lines of headroom against a
numerator that has been seen moving by two between runs on a CI machine.