espressif: refuse peer access to NO_ACCESS characteristics

[dhalbert]

Diagnosis and code by Claude, reviewed by @dhalbert.

Bug

• On espressif, a peer could read a characteristic declared READ with read_perm=Attribute.NO_ACCESS, and write one declared WRITE with write_perm=Attribute.NO_ACCESS.
• nordic and zephyr-cp refuse these with ATT Read Not Permitted / Write Not Permitted.
• Cause: NimBLE has no separate permission setting for a characteristic. Its BLE_GATT_CHR_F_READ and BLE_GATT_CHR_F_WRITE flags both declare the property and allow the access.
• Characteristics that use NO_ACCESS without declaring the matching property, such as StreamIn in adafruit_ble, were not affected.

Fix

• bleio_characteristic_access_cb() now returns BLE_ATT_ERR_READ_NOT_PERMITTED or BLE_ATT_ERR_WRITE_NOT_PERMITTED for NO_ACCESS.
• The declared properties are unchanged, matching nordic and zephyr-cp.
• Reads with no connection still succeed. NimBLE calls the callback that way to get the value for some notifications and indications.

Testing

Metro ESP32-S3 with this PR as peripheral:

Central	Test	Result
nRF54LM20 DK, zephyr-cp	read/write NO_ACCESS characteristics	read not permitted, write not permitted
nRF54LM20 DK, zephyr-cp	ordinary read and write, over-length write to fixed_length	unchanged
Linux host, bleak	READ + NOTIFY characteristic with NO_ACCESS read permission	properties still include read; read refused with Read Not Permitted; notifications received
nRF54LM20 DK, zephyr-cp	ble_uart_echo_test.py / ble_uart_echo_client.py from the BLE library examples	echoes received

[tannewt]

Thank you!