Fix RP2040 task lock acquire ordering

[Old-Ding]

Description

Fixes #1430.

vPortRecursiveLock() used spin_try_lock_unsafe() for the uncontended RP2040 task/ISR lock path, then immediately read lock-protected bookkeeping. The blocking path already gets acquire ordering from spin_lock_unsafe_blocking(), but the successful try-lock path did not.

This adds an acquire fence only on the try-lock success path. The contended path is left unchanged so it does not receive a duplicate fence.

Test Steps

• Inspected the RP2040 lock flow in portable/ThirdParty/GCC/RP2040/include/portmacro.h.
• Compared against pico-sdk spin_lock_unsafe_blocking() / spin_try_lock_unsafe() definitions to confirm only the try-lock fast path lacks acquire ordering.
• Ran git diff HEAD~1 HEAD --check.
• Verified the modified file uses CRLF line endings.

Not run: RP2040 hardware build/runtime test; the local Windows environment does not have cmake or arm-none-eabi-gcc installed.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

#1430

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Old-Ding]

Follow-up verification:

• The acquire fence is intentionally on the successful spin_try_lock_unsafe() fast path only. The blocking path already gets acquire ordering from spin_lock_unsafe_blocking(), so this avoids adding a duplicate barrier there.
• This matches the root cause described in [BUG] RP2040: task-lock fast path missing acquire barrier #1430: the fast path became the lock owner before reading lock-protected bookkeeping, but had no acquire edge.
• git diff --check origin/main...HEAD passes on the branch.

I still do not have an RP2040 hardware/build environment available locally, so this remains source-level and memory-ordering validation rather than a board runtime test.

[Old-Ding]

Maintainer ping: SonarCloud is green, the branch is mergeable, and this is scoped to the RP2040 task lock acquire ordering. Could this be routed for kernel/port review when possible?