Dropbox Account Id vs UID

"The solution for mapping old account IDs (uid) to new account IDs (account_id) seems to be a proactive call to the V2 API with an existing token to retrieving account_id. Is this correct?"

That's correct, you should call /2/users/get_current_account with the existing access token to get the account_id.

"Does this mean that we need to get every user (we have tens of thousands) to use our app in some way so we can piggyback a call to get account_id before the V1 api is shut off? If a user takes a hiatus from our app and then tries to use it after the V1 API shutoff, there would be no way to associate the IDs at that point, correct?"

You don't technically need to do this before API v1 is retired. Also, you don't really need to wait for users to be active to make this API call. As long as you have the access token, e.g., for a server-side app, you can just make the API call whenever you'd like. (For a client-side app, yes, you'd have to have them run the app, since you presumably don't have the access token anywhere except on the client.)

"I don't suppose there is a way for you folks to add uid to the get_current_account return?"

I've sent this along as a feature request, but I don't have any news on that.

"Barring that, is there a better way to do this to prevent some users being caught on the outside of the transition?"

I do recommend just going through all of the existing access tokens to get and record the account_id.

"Will existing tokens remain valid after the V1 shutoff?"

Access tokens aren't being deactivated. In fact, if you have OAuth 2 access tokens, you can use those directly on API v2. (One exception there is if your app happens to use the "file type" permission, which isn't supported by API v2.) If you have OAuth 1 access tokens, you can migrate them to OAuth 2 using API v2's /2/auth/token/from_oauth1.