Q1.
It is considered a good practice to prioritise completing work over starting new work. So, in your example, it would make sense for the developer to focus on fixing defects rather than starting new stories.
Remember, the goal of a sprint is to complete valuable work, not to have lots of work in progress.
Q2.
If the team feels they won't complete the work they planned in the sprint then they should let the Product Owner know. This helps to set the expectations of the Product Owner and gives them an opportunity to re-prioritise based on the new information.
Failure to complete work in a sprint is usually a result of either taking too much work in to the sprint or something unexpected impacting on the team during the sprint. Neither of these are a disaster, but a team may wish to bring them up in their retrospective to see if there are any lessons to be learned.
Q3.
If there is unfinished work in a sprint then it does not contribute towards the velocity calculation for the team. Usually this means the velocity goes down and so the Scrum Master would encourage the team to bring less work in to future sprints.
Q4.
If the tester finds defects from previous sprints then they should be raised with the Product Owner and added to the backlog. If the Product Owner regards fixing the defects as a priority they may suggest bringing them into the current sprint. It would be up to the team to decide if this is appropriate and they may wish to remove some existing planned work to compensate for the added scope.