You have a firm deadline and presumably something with a lot of unknowns that needs to be shipped. That's pretty risky. Here's how I've tried to get a handle on similar risks with a background in statistics and operations research. (Please forgive me for the length.)
For 1., 2., and 3., as frequently and synchronously as feels reasonable. Having a synchronous ritual of closing out the day (as opposed to opening it as is all too common) is tremendously helpful ("What did you all get done today? What warrants concern? Now, go home!"), and given that you're working in sprints, that reporting period should be good enough for most of the heavier-hitting touchpoints. Hijacking your sprint retrospectives for this is perfectly fine. If you need to meet synchronously more often for housekeeping, you'll know.
One-on-ones are a personal thing. Again, use your best judgment.
If the andon cord is pulled and kills the sprint early, say, kick your manager a quick email to let them know what's up. Their time is likely more valuable than yours, and it's worth trying to have trust that they'll let you know if they feel a synchronous meeting is necessary. Otherwise, the same advice on one-on-ones and other synchronous recurring meetings applies.
Everything else can be over email or your asynchronous messaging service of choice.
For 4., find someone with an MLIS degree. Seriously. Hire a librarian.
For 5., I'd strongly recommend adopting a practice that tries to minimize context switching as much as possible: just as in operating systems, context switches here are utter killers of performance and will slow you the hell down. Namely, if you have support obligations (for "site up," say) alongside needing to work on shipping and improving a product, establish a rotation (or possibly more than one) and include fixed-date product backlog items reflecting that/those rotation(s) to be considered during sprint planning that temporarily completely remove those individuals from product work. This will help keep those facts in front of you and make sure that the sprint workload commitment "feels right" given the regular reallocation of labor.
Completely removing those folks from product work will also help with bus factor concerns.
The team captain should run interference as much as possible for other interruptions like middle management drive-bys.
For 6., the name of the game here is what's called "one piece continuous flow:" the team is what ultimately ships things, not individuals, but it's the individual contributors coming together in lock step that enable each piece to be shipped. Folks going off on their own is fine in moderation (say, e.g., when reading and subsequently formulating comments to a design document or a report), but it can't be the norm.
Make your product backlog items trackable in a spreadsheet and try as best as you can to eschew relying on tools like Jira. I've had reasonable success with just giving suits an Excel spreadsheet with some VBA macros and pretty graphs: a lot of them know that tool well enough to make it work it turns out. Jira's nonetheless pretty familiar these days, but the complexity inherent in organizing work in epics and sprints and with tags and projects and workflows and screen schemes is a little too tempting when the actual work gets hard. Cut out as much meta-work as you can. Meta-work is expensive waste, and it, like context switching or rewriting your Emacs or fvwm configuration for the umpteenth time, will obliterate your performance.
As a corollary regarding meta-work, you can't scrub your bug tickets if you don't have bug tickets to scrub to begin with.
The team captain should have a habit of "management by wandering around" if they've doled out sprint work for the day to two or more subteams, albeit in a more systematic and regular and regimented fashion than the name implies. They should have a good "feel" for when folks are stuck and be willing to break through the bashfulness sometimes inherent with impostor syndrome by jumping in to pair with them. That feeling of not being good enough or a waste of time entirely evaporates when there's someone experienced roaming around to help proactively.
This all said, mobbing or pairing is only good to start, but you really need a collaboration of someone with proper product ownership (and not merely project management) and a sort of team captain on the development team itself to chart a course and make adjustments.
For 1., 2., and 3., as frequently and synchronously as feels reasonable. Having a synchronous ritual of closing out the day (as opposed to opening it as is all too common) is tremendously helpful ("What did you all get done today? What warrants concern? Now, go home!"), and given that you're working in sprints, that reporting period should be good enough for most of the heavier-hitting touchpoints. Hijacking your sprint retrospectives for this is perfectly fine. If you need to meet synchronously more often for housekeeping, you'll know.
One-on-ones are a personal thing. Again, use your best judgment.
If the andon cord is pulled and kills the sprint early, say, kick your manager a quick email to let them know what's up. Their time is likely more valuable than yours, and it's worth trying to have trust that they'll let you know if they feel a synchronous meeting is necessary. Otherwise, the same advice on one-on-ones and other synchronous recurring meetings applies.
Everything else can be over email or your asynchronous messaging service of choice.
For 4., find someone with an MLIS degree. Seriously. Hire a librarian.
For 5., I'd strongly recommend adopting a practice that tries to minimize context switching as much as possible: just as in operating systems, context switches here are utter killers of performance and will slow you the hell down. Namely, if you have support obligations (for "site up," say) alongside needing to work on shipping and improving a product, establish a rotation (or possibly more than one) and include fixed-date product backlog items reflecting that/those rotation(s) to be considered during sprint planning that temporarily completely remove those individuals from product work. This will help keep those facts in front of you and make sure that the sprint workload commitment "feels right" given the regular reallocation of labor.
Completely removing those folks from product work will also help with bus factor concerns.
The team captain should run interference as much as possible for other interruptions like middle management drive-bys.
For 6., the name of the game here is what's called "one piece continuous flow:" the team is what ultimately ships things, not individuals, but it's the individual contributors coming together in lock step that enable each piece to be shipped. Folks going off on their own is fine in moderation (say, e.g., when reading and subsequently formulating comments to a design document or a report), but it can't be the norm.
Make your product backlog items trackable in a spreadsheet and try as best as you can to eschew relying on tools like Jira. I've had reasonable success with just giving suits an Excel spreadsheet with some VBA macros and pretty graphs: a lot of them know that tool well enough to make it work it turns out. Jira's nonetheless pretty familiar these days, but the complexity inherent in organizing work in epics and sprints and with tags and projects and workflows and screen schemes is a little too tempting when the actual work gets hard. Cut out as much meta-work as you can. Meta-work is expensive waste, and it, like context switching or rewriting your Emacs or fvwm configuration for the umpteenth time, will obliterate your performance.
As a corollary regarding meta-work, you can't scrub your bug tickets if you don't have bug tickets to scrub to begin with.
The team captain should have a habit of "management by wandering around" if they've doled out sprint work for the day to two or more subteams, albeit in a more systematic and regular and regimented fashion than the name implies. They should have a good "feel" for when folks are stuck and be willing to break through the bashfulness sometimes inherent with impostor syndrome by jumping in to pair with them. That feeling of not being good enough or a waste of time entirely evaporates when there's someone experienced roaming around to help proactively.
This all said, mobbing or pairing is only good to start, but you really need a collaboration of someone with proper product ownership (and not merely project management) and a sort of team captain on the development team itself to chart a course and make adjustments.
Hope this helps.