I think it is important to establish the difference between Connectors (integration that Pega consumes) and Services (integration that Pega exposes). In general, the Int layer holds all the assets that are relevant to connect Pega to downstream systems (meaning Connectors and related assets). Services, on the other hand, should be defined at Work layer (or even Data, depending on what are we going to expose). Another approach to hold Services is to use something similar to what Pega API uses - A higher layer on the structure with visibility to all your application (Pega-API...).
In other words, Int layer does not necesarily have visibility to Data and Work layers, but Data and Work layers will always have visibility to Int layer.
With that said:
1) Yes - Create something like XXX-Data-AppExtension, and use OOTB Embed classes.
2) No - See my comment above.
4) No - See my comment above.
5) Not sure what you are talking about here.
6) In general Yes, but try to keep the minimum logic at the Int layer - Just enough to do the mapping that is required to transform the information from the system you are integrating with.
7) Yes - There are circumstances where it can be interesting to have some flows defined at Data level, but usually it's not the case.
8 & 9) I don't understand these two questions - In general, properties have to be defined at the layer they are applicable.
Regarding (1), a Connector can default its URL using Global Resource Settings syntax, e.g., =D_EnvSettings[<params>].someURL. A Data Page entirely dedicated to supplying URLs for different environments for different purposes would use a class such as XXX-Int-EnvSettings, hence be part of the Integration layer.
Global Resoure Setting (GRS) is considered as Int Layer. Also GRS pyEndPointURL can get any applied to class even Embed- , Rule-, Data-
But Data Page holding the Global Resoure setting pyEndPointURL is considered in Data Layer since is a data page? question is holding all environment urls is considered in which layer Work- , Data- , Int- ?
I prefer to use the word "partition" when referring to the loose coupling that should exist between a Application's Work/Data partition and its Int partition. The word "layer" is already used to refer to layers of built-on applications.
Nothing prevents you from defining URL values in the Work/Data partition but, in general, that partition should be used for Business Logic. An Application should not care how its data is sourced. This follows from the long-standing Separation of Concerns (SoC) principle mentioned in the 7.3/4 LSA course.
Again, a Data Page that strictly contains URLs would belong in the Int partition.