apply type checks in Blackboard::set when the key is remapped

[aysha-afrah26]

Blackboard::set() looks the key up in the local storage only, so a key that a SubTree remapped into the parent blackboard never matches and the write always falls into the create-a-new-entry branch; createEntryImpl() follows the same remapping and returns the parent's existing entry, which is then overwritten with no type check at all. The result is that the same write behaves differently on the two sides of a subtree boundary: an unconvertible string written into an int entry through the remapping is stored as-is, leaving entry->info saying int while the value holds a std::string, a convertible string like "99" is kept as a raw string instead of being parsed to the declared type, and a safe int to uint8_t conversion that succeeds locally throws through the remapping. Every setOutput() on a remapped port takes this path, because the entry is created in the parent blackboard at build time and the subtree storage never holds the key. The workaround comment in set_blackboard_node.h ("avoid type issues when port is remapped") suggests callers have been compensating for this already. I ran into it while looking at the lookup asymmetries left after #1192. The fix resolves the entry with getEntry(), the same remapping-aware lookup every reader uses, so an existing entry goes through the type-checked branch and only a genuinely new key reaches createEntryImpl(); set() is an inline template in the header, so there is no ABI change. The regression test fails on master on all three behaviors and passes with the fix, and the full suite stays green.