Answers
Question 1: "Is [finishing early to allow for testing] an acceptable request?"
Answer 1: It is completely reasonable because in Scrum, the Development Team is self-organizing:
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - Scrum Guide
This means, you choose the way you work. Period. If you think finishing 1/2 day ahead is an improvement, then you should do it. This is the Development Team practicing self-organization by solving its problems itself.
Question 2: How do other development teams ensure they meet a definition of done that includes "in house testing complete" within a sprint?"
Answer 2: They decompose work into small-enough chunks and ensure they are cross-functional:
...with all of the skills as a team necessary to create a product Increment - Scrum Guide
Cross-functional means, the team should posses all the people, skills, tools, etc it needs to make work "Done" within a Sprint. In your example, this would mean testing skills, tools, and maybe QA people are needed on your Development Team.
As they get better, they shorten and amplify feedback loops in their development processes and strengthen their cross-functionality by learning new skills from each other.
Bigger Fish to Fry
There are bigger problems than needing to complete testing work within the Sprint. In no particular order:
You've got a Project Manager, not a Product Owner
This person is quoting to a customer in hours, mapping those hours to story points and planning Sprints for the Development Team. God help you if this translates to a fixed scope, fixed timeline situation. The Development Team and/or the Product Increment may not survive that sort of ordeal. This is a formula for cutting quality to meet a deadline or death-marching to a date everyone knows can't be hit.
The Development Team is not Cross-Functional
If someone outside the Development Team has a big red button that can make work un-"Done", the entire planning aspect built into Scrum becomes unreliable and seriously un-empirical; the Scrum Team can't know how much work it can get "Done" per Sprint and can therefore not create forecasts, form Sprint Goals, plan releases, etc. This is a serious problem, and a fundamental divergence from the lean manufacturing theory that spawned Scrum.
Absent/Weak Scrum Master?
I haven't inferred whether you have no Scrum Master or a Scrum Master who is weak or just very green. I say this as a Scrum Master who started out as green as green could be and who struggles daily to act with needed courage. If this SM exists, she/he should be fighting tooth and nail against these practices, removing what are massive impediments to the Development Team's progress, and shielding the team for metric weaponization and micro-management. Moreover, the Development team needs to expand to include as many other developers (QA are developers in Scrum) as are needed for the Development team to create increments of "Done" work in a single Sprint.
This is at a minimum. There are several improvements (s)he need to actively coach into being by serving the Product Owner, Development Team, and the Organization as a whole. For more on this, check out the Scrum Master's duties section of the Scrum Guide
I Know That Feel Bro
This stuff is hard, and it takes courage. I tell you these things not to make you feel attacked for trying but rather to encourage you; you stand to be terribly discouraged when you make nominal improvements to a Definition of "Done" but are being forced by to work to deadlines that deny you the craftsmanship of creating quality product that solves real problems for real people.
I've been there (and am there still in some ways) and want to encourage you by revealing that are likely root causes to the dysfunctions you initially brought to this exchange. I hope you find this answer is helpful on both fronts.
