Mount flag target type endpoints as FlagTargetTypes

[Deborah-Digges]

Summary

Adds the mount rule for the upcoming /flag_target_types endpoints (AUTH-6891):

FeatureFlagsTargetTypes: 'FlagTargetTypes',

The endpoints carry the feature-flags.target-types OpenAPI tag, so without a rule they'd surface as a FeatureFlagsTargetTypes service. This keeps them as their own resource named to match the standalone FlagTargets resource (/flag_targets), giving SDK surfaces like workos.flagTargetTypes / workos.flagTargets (see workos/workos-node#1683). /flag_targets needs no rule — its path-root-derived FlagTargets name is already correct, and derived operation names (list_flag_targets, create_flag_target_type, ...) need no hints.

The endpoints are still excluded from the published spec (@ApiExcludeController() in the monorepo); this rule takes effect when they go public, and was validated against a locally generated spec that includes them.

Link to Devin session: https://app.devin.ai/sessions/fdf25eeb8122400891ee756d079bfbeb
Requested by: @Deborah-Digges

[devin-ai-integration]

Original prompt from deborah.digges

Do you have all the information you need to able to do this task? https://linear.app/workos/issue/AUTH-6891/openapi-spec-sdk-regeneration-for-the-new-flag-target-endpoints

If so, can we start with the node sdk first?

I

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

Greptile Summary

Adds an exact SDK mount rule so upcoming feature-flags.target-types operations resolve to the standalone FlagTargetTypes resource.

• Maps FeatureFlagsTargetTypes to FlagTargetTypes.
• Documents the intended naming relationship with the existing FlagTargets resource.

Confidence Score: 5/5

The PR appears safe to merge because the new static mount mapping is consistent with existing service-name derivation and introduces no current failure path.

The change only adds an exact mapping for an upcoming service key, and the current specification contains no endpoints that could be incorrectly remounted by it.

Important Files Changed

Filename	Overview
src/policy/mount-rules.ts	Adds a forward-looking exact service remapping consistent with the repository’s existing feature-flag mount naming pattern; no actionable issue was found.

_{Reviews (1): Last reviewed commit: "Mount flag target type endpoints as Flag..." | Re-trigger Greptile}