Not a journal, this is a tech post to help others in the same situation.
Say you have a Slack message ts returned from search.messages, and you want to use conversations.history to retrieve it and get its thread_ts (parent). There's a slightly funky "inclusive=true && limit=1" technique there to make up for the lack of a "getSingleMessage" API, but I have found that, as of 2020-04-17, it doesn't retrieve any replies whatsoever. Whatever the latest/oldest/limit settings are, it's not a failure of the "inclusive" parameter, it just won't return any replies.
Slack's support pointed me to this sentence to suggest that using a "user" type oauth token should allow access to replies: "To use conversations.history with public or private channel threads, use a user token with channels:history or groups:history scopes." Nope, same behavior with user oauth token versus the bot token type.
My dirty hack: The information returned by search.messages, while missing a thread_ts attribute, does contain a "permalink" attribute that will have a "thread_ts=1234567.0500" on the end of it if it's a reply.
(message.permalink.includes("thread_ts=")) ? message.permalink.split("=")[1] : message.ts;
My real solution: Save the parent's ts way earlier in the workflow by slightly rearchitecting my application.