After much searching (and discussing), the answer is simply that the current version of ClickOnce doesn't work that way. The installer does not pass the URL onto the application up it's first run.
Here is what I have done for a workaround (and it works great).
Change my setup package to have all of the required files uncompressed and loose (as apposed to using a CAB file, or embedding them in the installer).
Make an ASP.NET application (using Routing for URL handling) that listens for a request to "mysite.com/Installer/00123/Setup.exe"
- Note: the route should listen for "/Installer/{ID}/*" where {ID} is 5 digits.
- There is actually no directory called "00123", but rather, I'm using ASP.NET Routing to pickup those requests and then I map it to my actual directory that has the installer file in it.
I then hijack the request (parse the setup.exe to find the embedded URL that tells the installer program where to find the rest of the files... I then replace "/00000/" with the request URL that the user went to - in this case "00123".
- As each file is being requested, I know which "version" of the file to send, because the ClickOnce Installer will be looking for "mysite.com/Installer/00123/SomeFile.dll" (or whatever).
Instead of using a 5-digit ID, you could use a GUID... it's up to you.
This solution works great for our organization... we currently have 37 clients who require unique customizations to their installer package, but we only have to actually build and publish ONE installer package and simply use the hijack method above.
At this point we have placeholders that we swap out so that it's easy to customize installers for as many clients as we want.
Example: in the app.config file we have displayName="{OrgName}" which is automatically replaced by one of the values in the database.