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