Having a large amount of carryover between sprints is a sign that stories were not properly groomed, fixing this requires a lot of work with the product owner to clarify requirements and create a firm definition of done. Some of this may be how you plan your sprints, they should only be as big as the amount of points you actually delivered in the past, not just everything that a customer wants now. If you have a product owner that wants more in a sprint than you know you can accomplish you need to push back and get the properly prioritized set of stories that fit your sprint size and take on no more than that. In a scrum/agile methodology its the responsibility of the dev team to ensure that they manage the size of a sprint to only be as much as they can do.
You seem to also have a belief that Agile means delivering more faster or your customers have that belief. This is not true in the sense that most people believe it to be. When agile people say they deliver working software faster they are constraining working software to be only what was in the sprint or previous sprints. You can deliver a site that has a working payment system faster, but its not going to have search, reviews, photo galleries, wish lists, etc. Agile guarantees working software faster, not necessarily feature complete software faster (though that can happen with a mature team).
The agile process isn't super great at explaining how hard deadlines are managed, it's generally more implied. It's managed by taking the estimated story points of the feature and using velocity to work backwards to get the latest sprint that these items could go in to deliver on time. If features are not high enough on the backlog to get into sprints before they can be finished on time it needs to be brought to the attention of the product owner so they can prioritize accordingly. Ensuring your backlog can prominently display deadlines for items or having a separate tracker for deadlines that is reviewed regularly during grooming are good ways to keep on top of these things. Your product owner will work with you to prioritize work to meet deadlines that are truly important, sometimes you may need to actually miss a deadline that you said you would for them to understand you can only fit so much in a sprint (I'm not advocating doing this on purpose, but sometimes people need a wake up call or teams are overly dramatic about deadlines).
As far as managing technical debt goes, the only real way that will work is to enforce the boy scout rule of improving code as you go and baking that in to estimates. Pure tech debt stories can be created, but its extremely rare that they ever hit high enough priority to be worked on. Other options like occasional maintenance sprints, or setting X hours a week as clean up/free time/training tend not to work as well since there will be pressure to use that time to work on higher priorities.