bluetooth: fix GATT server DB exhaustion on disable/enable cycles

[liuX10]

Summary

Fix GATT server static DB exhaustion across disable/enable cycles.

bt_sal_gatt_server_disable() previously only unregistered GATT/ATT callbacks without cleaning up the server_db[] and server_svcs[] static arrays. Each disable/enable cycle left stale attributes occupying slots, so attr_count kept growing until it reached CONFIG_GATT_SERVER_MAX_ATTRIBUTES and new service registrations failed.

Changes:

• bt_sal_gatt_server_disable() now iterates server_svcs[] and unregisters every active GATT service from the zephyr stack, deletes the associated SDP records, frees each attribute's user_data/uuid memory, and resets server_db/server_svcs/attr_count/svc_attr_count to their initial state before unregistering callbacks.
• if_gatts_shutdown() is reordered to call bt_sal_gatt_server_disable() before freeing the upper-layer service list, ensuring zephyr-side unregistration completes while the static DB is still consistent.

Impact

• Build: no Kconfig or API change
• Hardware: applies to all targets using the zephyr GATT server backend
• Compatibility: behavior change only on the disable path — resources are now fully released; no functional impact on normal enable/register/use flows
• Memory: slightly more work in the disable path; prevents long-term slot leakage and eventual registration failures

Testing

• Reviewed the user_data/uuid lifecycle in gatt_db_add() and remove_from_server_db() — the new free pattern matches existing cleanup semantics, no UAF/double-free introduced
• Verified that bt_gatt_service_unregister() is synchronous in zephyr, so freeing attribute memory after unregistration is safe
• Manual scenario verification (from the original bug log): repeated gatts register → disable → enable cycles no longer leave stale server_db entries

[chengkai15]

mind:manager->started = false now executes after bt_sal_gatt_server_disable() rather than before