Use the console, but update all the tokens so they are referring to the browser tokens. Not great as you have to change some of the code.
Activate my profile and then see what value I get after the profile is run. You can view this with the mboxTrace debugging tool (with the authorization token). Here is a help page which outlines how to get the authorization token and how to use the mboxTrace.
Note that for at.js implementations mboxTrace will be part of the mbox request response. If you view the network request in Chrome's debugger wit the preview mode you can easily see the different parts of the trace. For profile scripts you'll find them under profile > after execution > profileAttributes.
This is a tricky use case. I'd try to figure out a better trigger. Ideally the server that is building the html page could populate a variable in the head that could be picked up by Target with the TargetPageParams function. Though technically you could add some JS to the page that checks for the div and then fires a getOffer() that qualifies for the activity. This presents flicker scenarios though, as this second request will most certainly fire after the page has begun rendering.
Yes. If you modify the edit at.js settings you need to redownload and re-deploy the file.
The token parameters listed in the create profile scripts page will update if you switch to mbox vs profile.
Model and subcat are the names of custom profiles that were used in this example. They were sent over an mbox request with the "profile." prefix.
I think that's the primary stuff. You might find some stuff on github, but I think that's more the SPA extensions.