It sucks being on the critical path as normal developer, especially if you're late. When you're the senior developer, that the team is looking to for leadership, it's even worse.
When work for most of the team is stalled waiting on some critical piece what should the rest of the team do? We have limited access to the critical piece so others will simply be waiting no matter what we do. When the others are looking for advice on what to do what's a good answer?
Improve unit tests, functional tests, documentation, tools, etc. There's a plethora of things that can be done in down-time while waiting for the critical path to catch up.
While I like the answer about improving tests, documentation, etc., and it is a good one you can also look at:
It is also a good idea to start the "lessons learnt" phase now by recording that such critical components need to be started earlier in the development process, possibly before the rest of the team is assembled.
If a critical piece is already late, there's no guarantee it won't slip even more. What then? You just wait forever? That is not the kind of answer you want to have to tell to upper management.
One way to manage the risk is to start work on a simulator (harness, shim, stub, whatever you want to call it) to take the place of the missing critical piece.
Does it have a defined interface? Implement it.
Does it have detailed documentation? Imitate it as best as you can.
Is it just someone's idea? See if you can get a prototype.
That way, when they slip schedule again, you have an ace in your back pocket to close the gap. Not only will your team be unblocked (they can integrate with the simulator), but you will gain a valuable software asset.
If they slip schedule even more, use the time to write automated integration tests (against your simulator, for now). That way, when they deliver the real thing, you can just run your tests and detect any behavioral differences between the mockup and the deliverable. This will let you zero in on spots that you have to revise. As a bonus, you will quickly get an idea of how much they cut corners as their time ran out.
If the critical component has a known interface and if there is no hope of getting it done in a short time, why not build a test double (for example a mock)?
This would allow the team to carry on coding, although the test results would be slightly less meaningful.
Apart from the obvious "do all those things you did not get around to doing thus far", it sounds like you and your team lack the peace of mind to do anything unrelated to the late project. Which is understandable but not helpful.
So the real problem may be to be relaxed about it. I am not saying indifferent. Be concious of your responsibility, of what you can do to help and if that leaves you with time on your hands, enjoy it. You cannot nor have to be on your toes all the time. If you are a leader, I would say this should be your message. Transfering your nervousness to the team will not make a more productive team when it matters.
You don't say what methodology you're using which makes it tricky to advise exactly.
Where I work if there is a blocker, it is every hand to the pump doing whatever they can to expedite the development.
Consider if there might be a wider problem with you as the lead taking on too much. Yes, people will be looking to you for technical leadership but that doesn't mean some of your more able team members can't share the workload if they're mentored.
Aside from this, is there any other non-critical work they can get ahead on? Also, is there any work they've completed that could be further polished (refactored, removing technical debt, documentation, adding tests etc).
If there really isn't anything, give them something - go thru logs, builds, documents, test plans, designs, diagrams, write agendas, arrange meetings, hold brown bag sessions, share knowledge etc. There is always something to do. If people are willingly just sat around doing nothing on the company coin that should be escalated as they're clearly not team players.