Connect one Google Cloud root.

Set up a read-only Google Cloud service account so the Sythe Labs platform can read Cloud Asset Inventory for exactly one resource root.

Context:
- I am already signed in to the gcloud CLI with an account that can administer IAM at the root below.
- Use the gcloud CLI only. Do not open the Google Cloud console and do not install anything.

Ask me for these three values first, then echo them back before running anything. The $NAME placeholders below are not set in my shell, so substitute my answers into the commands:
1. ROOT_KIND - organization, folder, or project. This is the highest resource whose descendants Sythe Labs should read.
2. ROOT_ID - the numeric id for an organization or folder, or the project id for a project.
3. SA_PROJECT - the project id that will own the service account and the enabled API. It may be the same project as ROOT_ID.

Run these steps in order. Stop at the first failure and show me the exact gcloud error.

Step 1 - enable Cloud Asset Inventory in the service-account project:
gcloud services enable cloudasset.googleapis.com --project="$SA_PROJECT"

Step 2 - create one dedicated service account. Reuse it if it already exists; never create a second one:
gcloud iam service-accounts create sythe-labs-asset-reader \
  --project="$SA_PROJECT" \
  --display-name="Sythe Labs Cloud Asset Inventory reader"

Its email is sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com

Step 3 - grant roles/serviceusage.serviceUsageConsumer on the service-account project:
gcloud projects add-iam-policy-binding "$SA_PROJECT" \
  --member="serviceAccount:sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com" \
  --role="roles/serviceusage.serviceUsageConsumer" \
  --condition=None

Step 4 - grant roles/cloudasset.viewer at the root so it inherits to every child resource. Run only the one command that matches ROOT_KIND.

organization:
gcloud organizations add-iam-policy-binding "$ROOT_ID" \
  --member="serviceAccount:sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com" \
  --role="roles/cloudasset.viewer" \
  --condition=None

folder:
gcloud resource-manager folders add-iam-policy-binding "$ROOT_ID" \
  --member="serviceAccount:sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com" \
  --role="roles/cloudasset.viewer" \
  --condition=None

project:
gcloud projects add-iam-policy-binding "$ROOT_ID" \
  --member="serviceAccount:sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com" \
  --role="roles/cloudasset.viewer" \
  --condition=None

Step 5 - create one JSON key:
gcloud iam service-accounts keys create ./sythe-labs-google-cloud.json \
  --iam-account="sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com" \
  --project="$SA_PROJECT"

If Step 5 fails because of the constraints/iam.disableServiceAccountKeyCreation organization policy, stop and tell me. This connector requires a user-managed JSON key and has no OAuth or Workload Identity Federation fallback, so the connection cannot proceed until that policy permits a key.

Rules:
- Grant exactly the two roles above. Do not grant Owner, Editor, Viewer, or any other role, do not enable another API, and do not create or change any other resource.
- Never print the contents of the key file and never send it anywhere. Leave it on my machine.

When every step succeeds, print exactly these three lines:
ROOT_TYPE=<organization, folder, or project>
CANONICAL_ROOT=<organizations/ID, folders/ID, or projects/PROJECT_ID>
KEY_FILE=<absolute path to the JSON key file>

I select ROOT_TYPE as the root type, paste CANONICAL_ROOT into the canonical resource name field, and upload KEY_FILE on the Sythe Labs Google Cloud integration page.