Cross-Database Impersonation Fail for Service Account
Correct: Impersonation / EXECUTE AS, by default, is quarantined to the initial database. In order to get around this you need to do either set the initial database to TRUSTWORTHY ON (not a great option, so should be viewed as a last resort), or create a Certificate that can be in both the initial DB and the destination DB that can be used to link the desired permissions (and then you don't need Impersonation at all).

I have several examples of doing this across various answers here on DBA.StackExchange. Try these first:


Stored procedure security with execute as, cross database queries, and module signing (this one goes through, step by step, showing how Impersonation, Cross-DB Ownership Chaining, and TRUSTWORTHY work, and then how module signing eliminates the need for all three of those options).
Permissions in triggers when using cross database certificates


Now, given the new information added to the question regarding:


  The project that precipitated this question is an iterative deprecation so I think cert-signing may end up being a rather large administrative overhead as time goes on.


and:


  If it is possible to use this stored proc as a wrapper to execute restricted actions agnostic of who calls it, that's the end-goal. ... I am confident that the SProc cannot be improperly modified, so anything that executes from inside it may be highly permissioned - in the hopes that I don't need to administer perms for the ServiceAccount one-by-one.


the direction to take can be narrowed down. Usually the goal is to be as granular as possible with the permissions, so it sometimes takes some extra steps to get to a least-privileged setup. But that doesn't mean that you can't take fewer steps to be less granular when the situation calls for it.

One of the (several) wonderful aspects of module signing is that you are effectively giving permissions to the code, not to people. So you can control the who can make use of the permissions by properly setting permissions on whatever code (i.e. Stored Procedures, Functions, Triggers, etc) is being signed.

Assuming you want both Server/Instance -level and Database-level permissions, even if you don't end up using most of what will be allowed, you can do the following:


Create a Certificate in [master].
Create a Login from that Certificate.
Add the Certificate-based Login to the sysadmin Fixed Server Role.
Switch to the Stage DB
Re-create the same Certificate in this DB (either by backing it up to a file on disk OR by extracting both the Certificate and the Private Key to variables or a local temporary table as shown in my other answers).
Sign the Stored Procedure with this Certificate via ADD SIGNATURE.


That's it! The Stored Procedure, regardless of who executes it, can do anything it was coded to do. And if that code changes, you will need to do the ADD SIGNATURE again. But the Certificate-based Login cannot be Impersonated, so nobody can use it to get "sa" privileges. And, if you use "encrypt by password" when creating the Certificate and do not give that password to anyone, then nobody will be able to sign other modules with it.

In this setup, the only on-going administration would be re-signing the Stored Procedure if you keep changing it.



Also, regarding your final attempt (i.e. alter authorization on object::spLoadStageToProd to sa;): that doesn't work because "sa" is a Login (Instance / Server -level), not a User (Database-level). So you can only grant permissions on database-level items to principals found in sys.database_principals.