You'll get a lot of 'ideal' Scrum Master behavior which if not favor at least do not harm engineers; but they do harm you as a leader / scrum master in the organization.
Some might tell you not to approach the developer. That is against the scrum values. As long as the developer is part of the team they need to adhere to the scrum values of openness and respect. Constructive feedback should be welcomed and respected from Day 1 to the last day.
So in no particular order; here are some of the changes you could propose to the team & the developer. (For all the below; I'm assuming you have strong conviction that the team's degrading performance is because of this developer.)
Bring out the most important metric from org perspective you would like the team to focus. Make your team understand how it contributes to the org goals. Do this exercise: Make your team members speak out loud the current feature they are working on; when do they expect to complete it and who are they collaborating with in case of any impediments. The goal of this exercise is for them to publicly own features/work items and hold themselves accountable. It also gives you a map of the battlefield: if any features are left out or too many people working on it, does it match the expected timeline, who is overloaded/underloaded, who is at the epicenter (most imp team member), etc. You can then take the important people/work items and strategize around it. Document all of this so that you can present to higher ups about your plan, findings, actions taken and results. If your claim about the developer in question is right; it will automatically put a spotlight on them and the team will need to offload them or pair up with them to get things done.
If you do approach them individually be ready to face them with the following data: minimum standard of quality & delivery expected. You don't want to show velocity, because velocity is a team metric and not individual. You want to get a history of the individual's work items, calculate their avg. lead time and any bugs / quality related side effects. Start by 'acknowledging' their efforts so far in the org. How well they started and performed and something you admire. Then 'recognize' the void that will be left when they leave the team. Finally inform them that you do 'respect' their decision to part ways but they expect the same level of professionalism and commitment from them as any other day. Ask them what they are working on currently and when they expect it to be completed. Inform them about the expectations of work and who they need to follow up if they're blocked and define a reasonable amount of time before they ask for help. Everyone has a different work schedule so I wouldn't worry about it as long as they deliver the result. Find someone to handshake / knowledge transfer and keep track of their meetings on a weekly basis.
Your goal as a Scrum Master is to enable people to get things done. Sometimes it means telling unmotivated people to stand up, put one foot in front of the other and teach them how to walk again instead of the team dragging them.
After every meeting with the said developer; send a meeting note listing in short / bullet points: what was discussed, what was agreed, what actions need to be taken, who to talk to and when to follow up.
If you need help, be sure to have a fellow Scrum Master (confidante, esp. better if that someone is outside your org) review your message / ideas / plan of action.
If you're a timesheet based organization and the developer refuses to follow any / all 'requested' & 'agreed' actions after 'multiple' requests; please talk to HR and discuss if not performing 'expected' daily activities classifies as an unpaid day / leave of absence. Give 3 warnings indicating that their last working day might be extended because of this or pay might get affected (confirm with HR / Manager before talking remotely anything about pay). If you're not comfortable talking about pay; just don't. Ask HR to set up a meeting with them.
I do not recommend #2 unless you as a scrum master will directly be held responsible by the client / higher ups for degraded performance. In most situations it is quite understandable that motivation & delivery drops when attrition increases. I would always recommend #1 in worst cases and #2 in the worst of worst cases. If you are new to the organization I would go with #1. If you've been in the org for multiple years and have a good reputation + connections and you face the worst of worst case; I would recommend #2.