CXP-898: add RawId annotations to resources for match_baton_id

[agustin-conductor]

Summary

Fixes CXP-898. Customers who preload resources and entitlements through Terraform (match_baton_id) end up with duplicates after sync, because the connector doesn't emit a RawId annotation.

C1's uplift matches preloaded objects against the RawId on the resource:

• Resources match when match_baton_id equals the resource's RawId, within the same resource type.
• Entitlements match on the pair (match_baton_id, slug), where match_baton_id is the parent resource's RawId.

See pkg/mapper/{resource,entitlement}/v2/uplift.go in c1. C1 never reads RawIds set on entitlements, so none are added here. Only resource-level RawIds made the GCP fix work (baton-google-cloud-platform#37).

Changes

Every resource builder now attaches v2.RawId set to that resource's ID:

Resource	RawId
Account	account ID
Workspace	deployment name
Group	account/<acct>/group/<gid> or workspace/<ws>/group/<gid>
Role	<role> (account) or <ws>:<role> (workspace)
Service principal	service principal ID
User	user ID

Groups use their composite resource ID because the same Databricks group is synced under both the account and each workspace. A bare Databricks ID could collide within the group resource type.

Resource, entitlement and grant IDs don't change, so existing syncs are unaffected.

Terraform example: match_baton_id = "account/<acct>/group/<gid>", slug = "member".

Testing

• go build ./..., go vet, go test ./... pass.
• New pkg/connector/raw_id_test.go checks that each resource type carries a RawId equal to its resource ID. The account resource isn't covered because building it needs a real client.
• Not yet checked against a live sync.

🤖 Generated with Claude Code

[linear-code]

CXP-898

[github-actions]

Connector PR Review: CXP-898: add RawId annotations to resources for match_baton_id

Blocking Issues: 0 | Suggestions: 0 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base e1f01d674bee.
Review mode: full
View review run

Review Summary

Every resource builder (account, workspace, group, role, service principal, user) now adds a v2.RawId annotation whose value is exactly the existing resource ID. Resource, entitlement, and grant IDs don't change, and no new API calls, scopes, or config are added, so B1–B9/BP1–BP5 don't apply. I scanned the full diff for security and correctness issues. I checked the vendored baton-sdk v0.32.1: v2.RawId exists there, and rs.WithAnnotation appends annotations rather than replacing them, so the separate WithAnnotation call in account.go keeps the ChildResourceType annotations. Group RawIds use the composite groupResourceId, so the same group can't collide between the account and workspace scopes. Account roles are the bare role name and workspace roles are prefixed with <ws>:, so role RawIds are unique within the type too. I applied the repo-local criteria: ID stability (G/I1) holds because the RawIds reuse the existing stable IDs. The logging, error-wrapping, span, JSON type-safety, and provisioning sections have nothing to check, since the diff doesn't touch those areas. The new table-driven raw_id_test.go covers every builder except the account builder, which needs a client. That builder's change is one line and matches the others. I found no new issues.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

None.

[github-actions]

No blocking issues found.