The third option would probably be the easiest way to achieve your goal. The only problem is, if the same group of users will be surveyed again in the future, it might not be so easy to determine whether the opt out was triggered by the user or by the workflow and you have to spend extra time structuring that.

After spending way too much time attempting to create the third solution through web service calls and becoming frustrated with the lack of precision available in the API, I stumbled on a fairly simple answer. Hopefully it will save time for anybody else looking for a workaround.
There is a workflow task named "XM Directory" which allows you to update contacts in a directory.

You can then select the mailing list you want to opt the contact out from, fill out the minimum information and then tick "Unsubscribe this contact" down the bottom. Despite this task being named "XM Directory", it will actually unsubscribe the contact from the selected mailing list (not the parent directory).
This ensures that any users that complete the survey are opted out from future communications to that mailing list, regardless of distribution method.

To address the issue noticed by Asif (good pickup!) you can add an additional XM Directory task which adds the contact to a separate mailing list (eg: "Survey completions"). The only difference is that you'll probably want to tick "Add it as a new transaction to your XM directory contacts" to avoid potentially overwriting the contact in the original mailing list.
You can then compare the opt outs from the original mailing list to the completions list - if they do not appear in the latter, they have opted out manually.
===
So to summarise here is a basic model of my workflow:
If you have multiple mailing lists and an embedded data field which identifies what list a user belongs in, you can just set up a workflow for each mailing list and add some conditional logic to check the relevant field.
I've posted a product idea here - if you would like to see this feature added in the future, please upvote and comment!

Bumping this old thread with a partial solution I’ve stumbled on 1.5 years later.

If you’re using an authenticator for your survey, there is an option to reload any previously saved progress upon user authentication.

As mentioned in the text below this option, you should disable ‘Allow respondents to finish later’ in Survey Options (I assume because it is cookie-based which could create a conflict).

I’ve tested this by partially completing a survey and then accessing it via anonymous link, and personalised email and SMS links. All three methods opened the survey to the same point, even if it was brand new session in a private window or separate device.

However this does fix the reminder issue noted in my initial post - when a user opens a personalised link in another channel, it actually creates a new survey instance and just loads their existing progress. Once they complete the survey, they will still receive any reminders for the channel that they did not complete the survey on. So you’ll still need to routinely update your opt-outs for the mailing list to avoid spamming.

Revising this after more testing to say that it actually does address this if the user takes the survey via email or SMS at some point. Anonymous links are the edge case here - if somebody only takes the survey via anonymous link, they will still receive email/SMS reminders. If they begin via an anonymous link, and then continue via email or SMS, it will link up the anonymous response and they will not receive reminders after they complete it regardless of the final channel used.

So basically, you will only need to update your opt-outs if you’re using anonymous links in conjunction with email or SMS distributions.

If you’re using an authenticator you can use both of ​@bgooldfed ‘s suggestions quoted below to a) ensure that someone who has started your survey via one distribution channel (i.e. SMS) can’t take it again using a different distribution channel (i.e. email) and to b) ensure that someone who has completed the survey via one distribution channel won’t receive reminders via a different distribution channel meant only for “unfinished respondents.” 

Note that I tweaked ​@bgooldfed’s first solution slightly. Instead of creating an entirely new contact list, I used my first XM Directory task to update the recipient in my contact list. I also added an embedded data field here called AutomaticOptOut and set it to “yes” so that everyone who has taken the survey gets a “yes” in the AutomaticOptOut column. 

Then I added a second XM Directory task where I unsubscribed the participant so that they wouldn’t get reminder texts/emails:

I can now differentiate participants who manually opted out from those who were automatically opted out via the workflow. 

Bumping this old thread with a partial solution I’ve stumbled on 1.5 years later.

If you’re using an authenticator for your survey, there is an option to reload any previously saved progress upon user authentication.

 

As mentioned in the text below this option, you should disable ‘Allow respondents to finish later’ in Survey Options (I assume because it is cookie-based which could create a conflict).

I’ve tested this by partially completing a survey and then accessing it via anonymous link, and personalised email and SMS links. All three methods opened the survey to the same point, even if it was brand new session in a private window or separate device.

 

However this does fix the reminder issue noted in my initial post - when a user opens a personalised link in another channel, it actually creates a new survey instance and just loads their existing progress. Once they complete the survey, they will still receive any reminders for the channel that they did not complete the survey on. So you’ll still need to routinely update your opt-outs for the mailing list to avoid spamming.

Thanks for sharing that ​@elbake, that’s certainly more graceful that my solution!

It’s probably worth ensuring the mailing list is private as well, otherwise you’ll be updating the manual opt out field for the user at the directory level Relevant doc

​@bgooldfed Good catch! I didn’t know that, but luckily my list is private.