If you have Target implemented on pages that are created with AEM, and you load those pages in the Target UI to compose a test experience then in response:
Target only "loads" those pages temporarily for you to compose the experiences.
Target actually saves the content modifications you make and a reference to what element on the page they are made, but otherwise does not store the page code.
The modifications for a given activity are saved to that activity and can only be used by that activity (unless you are using the swap offer/image features - those are stored as separate peice of code under "offers" in Target).
Great question. There is no sync-ing as you describe. If the change affects either the element modified in the test OR the reference path Target used to select that element it will break your test experience. You can verify this by editing the activity. On the experiences step, if Target notices changes to the DOM you'll get an error message. If those changes impact your test experience modifications you may not see them rendering correctly. You can also use the "</> code" viewer mode to see if individual modifications can't be applied. You'll get a warning listed next to them if that is the case.
It sounds like the page is published and created in AEM - if that is the case, you do not need to create a query parameter to tell Target to change the content. Target will read the AEM page so long as there is a global mbox using at.js. A parameter is not required. Target will keep the version of that experience in Target. All experiences are specific to Target, meaning that you are not creating the experience in AEM, unless you happen to be using the Target/AEM integration, in which case, you can follow the AEM workflow outlined in the reference...