Following my pattern in the C# forum, I'll answer my own question.
The issue is that the LocalSystem account, which most services run under by default, runs in it's own context. Thus, it doesn't have access to
USER drive mappings.
Or, as a very obscure and unenlightening
MSDN Article puts it:
A service that runs under a LocalSystem account or under a local user account can only access mapped drives that the service creates. Mapped drives are stored for each logon session. If a service runs under a LocalSystem account or under a local user account that does not create certain mapped drives, the service cannot access these mapped drives. Additionally, a service that runs under a local user account that creates certain mapped drives also receives a new set of mapped drives if you log off and then you log on again as the same local user.
The article then goes on to display massive code listings as a "work-around". Ignore all of that. The two relevant pieces of information are that you cannot use DRIVE MAPPINGS.
You can, however, use UNC Paths:
\\COMPUTER_NAME\SharedFolder\
The second clue is that the account used by the service, and thus by extension all processes it spawns, must have rights to the share. A "LocalSystem" account on a specific machine has no such rights. So, the service must run under a "User Account".
That's an inconvenience, to be sure, but can be handled by good installation documentation. In my case, my service application will be installed on the production machine by yours truly, so I can manually change the service Log On to a local user account.
When you use the Services applet in the Control Panel to do this, it will automatically add the requisite "Run as a service" privilege to that account.
Problem solved!