Sprint Velocity

Velocity is the rate at which work is Done. That's it. 

Any sophistry along the lines you propose therefore ought to be avoided. Also, rather than writing Product Backlog items for defects, it would be better to recognize that the initial work was not Done. The work did not therefore truly contribute to any throughput or velocity measure.

There is no carryover of work in Scrum. A useful Sprint Goal is either met or it isn't, and any undone work is re-estimated on the Product Backlog for possible consideration in a future Sprint Planning session.

Velocity is the rate at which work is done. If you are using stories and story pointing, you can count the story points associated with the done work and that is your velocity for that Sprint. If you wanted to, you could also apply the concept of yesterday's weather and take a rolling average of the velocity last few (3-8) Sprints. However, for any team using story points and velocity, I'd strongly recommend reading Ron Jeffries' 2019 blog post "Story Points Revisited", where the inventory of story points explores his current thinking and problems with this approach.

However, it seems like you have deeper issues that need to be solved:

1. Your work is "constantly pivoting". Given that you also talk about carrying over work, the Sprint Backlog seems highly unstable. Although responding to change and feedback is essential, some stability helps the team achieve its goals more consistently and adds predictability to delivery. I'd want to understand why the work changes within a two-week Sprint.
2. The idea of "dev" and "test" as separate roles introduces sub-teams. Although some specialization is natural, there are only a few instances where testing should be done independently. Even if it is, a better approach is to ensure quality is built in before independent testing. Having cross-functional teams and individuals can improve the flow of work.
3. If the "constraints, blockers, delays" are frequent, these would be good things to discuss at the Sprint Retrospective. The team should find ways to make sure that any prerequisites are in place before the work is started to allow it to flow from start to done. There could be opportunities to address root causes to minimize their occurrences if there are common impediments.

Why would you use story points as a measure of velocity, especially when your team has a difficult time determining them? Story points are guesses made at a specific point in time based upon the information available at that time.  When real work starts, new information is usually uncovered which would invalidate the original guess.  Even if you average across time, there is still no real guarantee that the calculation is meaningful. I highly recommend you read the blog post that @Thomas recommended.

If you really want to calculate useful metrics that will help the team on a long term basis, I suggest using flow metrics.  I suggest you read the book "Actionable Agile Metrics for Predictability" by Daniel S. Vacanti.  He explains how flow metrics can be used to help predict the ability to deliver work.  He has 3 books that all are valuable in my opinion.  And since you mentioned that you use Jira, there is a add-on that uses his methods to produce reporting for you.  

You do need to take a look at why the work is constantly changing.  I also think you should explore the concept of the Sprint Goal as is it used in the Scrum Guide. It can help your team retain focus during a Sprint so that they can deliver useful increments of value to the stakeholders.