feat: report bluetooth battery percentage

[drupol]

This PR resolves an issue where the battery percentage for the RAK4631 board was completely missing or permanently stuck at 0% over Bluetooth.

Changes Made

1. BLE Battery Service Fixes (Bluetooth.h, Power.h)

• Advertising Payload: Added Bluefruit.Advertising.addService(blebas) so the Battery Service UUID is properly advertised to scanning devices
• Initial Value Buffer: Added blebas.write(battery_percent) immediately after blebas.begin(). Without this, the characteristic length is 0 bytes when BlueZ initially queries it upon connection, causing Linux to silently drop the org.bluez.Battery1 interface
• Live Notifications: Added blebas.notify(battery_percent) in the update_pmu() routine so connected BLE clients receive automatic updates without needing to actively poll the GATT characteristic

Testing

• Compiled for rak4631
• Verified that bluetoothctl info on Linux now successfully exposes the Battery Percentage characteristic (0x2A19) upon connection.
• Verified that the battery percentage accurately reflects the real battery voltage instead of being clamped to 0%.

❯ bluetoothctl info FE:E7:AB:CA:47:C3
Device FE:E7:AB:CA:47:C3 (random)
        Name: RNode 2C68
        Alias: RNode 2C68
        Paired: yes
        Bonded: yes
        Trusted: yes
        Blocked: no
        Connected: yes
        LegacyPairing: no
        CablePairing: no
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
        UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
        UUID: Nordic UART Service       (6e400001-b5a3-f393-e0a9-e50e24dcca9e)
        AdvertisingFlags:
  06                                               .
        Battery Percentage: 0x64 (100)
        LE.Paired: yes
        LE.Bonded: yes
        LE.Connected: yes

[attermann]

Curious how much of this is Bluetooth related vs PMU. Your previous PR #78 implements battery status, but this seems to take it further with additional PMU logic. You mention "battery measurement multiplier" which seems like it would be part of the battery status PR.

[drupol]

Heya,

I think there might be a slight mix-up with the PR numbers in your comment ! You mention #78 implementing battery status, but I believe you meant #81.

You were completely right though: the PMU logic mathematically belongs with the base battery implementation ! To clean this up and make reviewing easier, I have reorganized the open PRs:

1. feat(rak4631): implement battery status reporting #81: I have moved the ADC configuration fixes (analogReference and analogReadResolution) here. They are strictly required because the 0.005068 multiplier needs a 3.0V reference and 10-bit resolution to work (otherwise the default nRF52 settings clamp the voltage to 0%). I have also updated the PR description to reflect this.
2. feat: report bluetooth battery percentage #83: This PR now strictly contains the Bluetooth BLE broadcasting logic and notifications. No more PMU logic.
3. feat: optimize BLE advertising intervals, clarify power management constraints #78: As an aside, based on your previous feedback regarding solar nodes, I have updated this PR to completely remove the Deep Sleep logic (which turned off the ADC). It now strictly handles Light Sleep (yield()) during inactivity.

Does this separation look good to you? Thanks again for the thorough review!

[drupol]

I rebased the PR against the latest changes.

Using it on all my RAKs successfully.