docs: Improve docs to mention Synthetics for Platform tools & GitHub endpoints being private

[agardnerIT]

By default, endpoints exposed by GitHub codespaces are private to the current, logged in user.

This is true for any "customer-apps" that are deployed using this demo. The logged in GitHub users will (obviously) be able to access the endpoints, but try it in an Incognito mode and you won't be able to access. This is good as it follows secure by default design and ensures that the demo system isn't open to the world.

However, this is the case for our core platform services: Backstage, ArgoCD.

Now, when the platform spins up and the DT OneAgent is installed, Monaco is triggered via an Argo post sync hook to create DT synthetic tests against both Backstage and ArgoCD. These tests run from a public synthetic node which DT maintains. This, in turn, means that the synthetic tests attempting to access Backstage and ArgoCD will fail by default. This is expected behaviour.

So:

1. We need to clearly document the above behaviour to avoid "it's broken" issues.
2. We need to clearly document how a user resolves this in their environment.

Warning: It is technically possible to tell GitHub to set the codespaces as public by default but I strongly suggest we do not do so, as it breaks the "secure by default" design pattern and opens up who-knows-what in terms of security risks.

[agardnerIT]

We cannot advise to open the backstage port publicly until Backstage has some authentication (eg. what is propose in #2). Otherwise anyone could create arbitrary content in an end-users Git repo.

Edit: Actually, the situation is worse. Backstage state that the auth isn't really meant for security:

An external user is a user that [is not an internal trusted user], for example a malicious actor outside of the organization. The security model of Backstage currently assumes that this group does not have any direct access to Backstage, and it is the responsibility of each adopter of Backstage to make sure this is the case.... As an integrator of Backstage you yourself are responsible for protecting your Backstage installation from external and unauthorized access... The sign-in system in Backstage does not exist to limit access, only to inform the system of the identity of the user.... The primary purpose of [the backstage auth plugins are] to restrict access to resources for internal users rather than Backstage as a whole.

So.. all in all, I think it's a bad idea to open backstage to the internet so, at this time, we should not advise this be done.