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.