Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
One is that whenever a characteristic is updated or a new entry is added to the accessory table, this change is stored as a configuration number update, which is part of the mdns text record. However, we don't advertise this text record update, rather we wait for the controller such as HAT to ask us for it ( in order to reduce network traffic and comply to HomeKit spec ). So recalculating the database wont be seen until HAT requests it, which takes place every couple of minutes.
The other thing is regarding the HAT tool itself. I had a look at replicating your test case, and found something interesting. Once I have dynamically updated the database, and try to rediscover it through HAT, HAT does not seem to issue a 'Discover' command (GET accessories), immediately after the Discover request, but rather 3 minutes later. I get the impression HAT is ignoring the request and simply getting the text record, seeing that the configuration number has been incremented and issuing a discover only then. I believe you may see this too if you have a look at the HTTP transport section (seen in your your screen shot, though not expanded to show details). Can you confirm this? If so, it may be something which will be addressed in next release of HAT.
I'm not seeing the wiced_heap_allocated_for_database" and "recalculated_size" to be same. This could happen if you executed wiced_homekit_start after wiced_heap_allocated_for_database.