If I understand you correctly, you are describing a “standard” distributed commit problem, the parties being your DB and Temporal’s activity manager.
Have you considered one of the “standard” and cheap solutions for this: generate a domain specific transaction id for each invocation of your activity, and pass it as an argument to the activity?
Have the workflow (your business logic) that invokes the activity generate a unique code. It is your business logic, so you can always make up a unique value that could never ever be re-used again! When the activity commits, store this code as part of the transaction in a way that allows efficient look up.
Then if the activity is retried due to a failure after commit, you will see the same unique id in the activity arguments. You use it to detect that the activity is being re-run, and if so you simply skip ahead to (re)sending the response.
I believe this will require zero additional support from the framework, and you can choose the best id generation solution for your specific application.
I hope I’m not totally misunderstanding your problem, or telling you something you already knew and eliminated as a possibility 
If there’s some fundamental reason this very old school approach is not suitable with Temporal I’d really like to understand why (I’m new here!).