fix(radios): allow backend activation despite reported rfkill hard block

[p0nti]

Summary

Let NetworkManager and BlueZ attempt radio activation even when the preliminary rfkill check reports a hard block. Retain a diagnostic warning and all existing backend error handling.

Motivation

On a Dell Latitude 5531 with Intel AX211/iwlwifi, disabling Wi-Fi in Noctalia produces:

dell-wifi: Soft blocked: yes; Hard blocked: no
phy0:      Soft blocked: yes; Hard blocked: yes

Re-enabling in Noctalia logs setWirelessEnabled: wlan rfkill hard block is active and returns without requesting activation from NetworkManager. nmcli radio wifi on alone clears both blocks and reconnects. The vendor platform soft block can manifest as a PHY hard block, so this initial observation must not prevent the backend from attempting activation.

The same early-return pattern exists in Bluetooth, and #3367 contains a report of a platform rfkill hard-block indication preventing an otherwise functional Bluetooth adapter from being enabled.

This is not an override of a real hardware switch: kernel enforcement remains unchanged. The patch only removes the client-side refusal to attempt the existing backend operation. Disable behavior and error handling are preserved.

Type of Change

• Bug fix

Related Issue

Fixes #3367

Testing

The two modified source files are byte-identical to the locally built and hardware-tested patch based on 29dab93. They were unchanged upstream when rebasing this submission onto main (4912b92).

• Full release build of the patched shell on 29dab93: meson setup build-radio --buildtype=release -Dtests=enabled -Db_ndebug=true and ninja -C build-radio -j 4 noctalia.
• Existing network_manager_security test passed; rerun before submission. This is an existing smoke test, not a new regression test for rfkill.
• Patched-shell configuration validation passed with the same two pre-existing local configuration warnings as the installed shell.
• Wi-Fi: reproduced the failure before patching; after starting the patched shell, the user confirmed disabling and re-enabling through Noctalia works.
• Bluetooth: Noctalia IPC disable/enable returned off/on, and BlueZ Powered returned true. No connected Bluetooth devices were interrupted. The ThinkPad-specific hard-block scenario has not been reproduced on this Dell.
• just format with clang-format 22.1.8 and git diff --check.
• A full rebuild of the newer main revision was not repeated; the modified files match the tested build exactly. Full test suite and physical hardware-switch coverage were not run.

Manual Coverage

• Tested on Niri
• Tested on Hyprland
• Tested on Sway
• Tested on another compositor
• Tested with different bar positions and density settings
• Tested at different interface scaling values
• Tested with multiple monitors

Environment: Arch Linux, Dell Latitude 5531, Intel AX211, NetworkManager. BIOS WLAN enabled and WLAN autosense disabled; user has write access to /dev/rfkill.

Screenshots / Videos

Not applicable: no visual/layout changes.

Checklist

• This PR is ready for review.
• I read and followed CONTRIBUTING.md and the project ethos.
• I ran just format with clang-format v22+.
• I ran relevant build/test commands and described their coverage above.
• I self-reviewed the changes.
• I checked for new warnings or errors in the affected radio path.
• No documentation changes are required: this restores the existing enable operation without changing configuration or IPC.
• No new user-facing strings or translation changes.
• Existing canonical config keys, IPC names, paths and identifiers are preserved.

Additional Notes

Prepared with OpenAI Codex assistance, reviewed against the existing activation paths, and tested on the affected hardware. Bluetooth hard-block behavior on other hardware and genuine hardware-switch cases would benefit from additional testing.

[ItsLemmy]

Thanks for the PR, can you try with my commit see how it behaves on your hardware., then report back.