fix use-after-free from dangling StringView in Blackboard::getKeys

[aysha-afrah26]

getKeys() hands back a std::vector whose elements point into the std::string keys of the internal storage_ map. The shared lock added by the earlier BUG-6 fix is only held for the duration of getKeys() itself, so the returned views outlive it. ExportBlackboardToJSON walks those views after the lock is gone, and that path runs on the Groot2 publisher server thread in response to a BLACKBOARD request coming off the network. If the tree ticks an UnsetBlackboard node (or anything calling Blackboard::unset) in that window, unordered_map::erase destroys the key string and the StringView the exporter still holds now points at freed memory; constructing a std::string from it is a heap-use-after-free. I hit it while stress-testing concurrent key reads against unset, and ASan pins the read to the std::string copy in ExportBlackboardToJSON with the free coming from unset. The test file already had a note that getKeys() could dangle on erase, so this finishes that fix by returning owning std::string copies made under the lock instead of views into storage. Worth calling out that the return type changes from vector to vectorstd::string, a small API change; all in-tree callers already copied into std::string anyway. The added regression test reads keys while another thread erases and reports the use-after-free under ASan before the change, clean after.