feat: allow LaunchDarkly project-wide flag prefixes

[greghuels]

Summary

• Adds a LaunchDarkly interactive migration prompt that lets users prefix every new Datadog flag key for a selected LD project, not only conflicting keys, so all flags from that project can share a consistent prefix.
• Detects an existing project prefix from migration metadata or previously migrated key shape and offers it first for re-migrations.
• Centralizes Datadog key planning for interactive runs so existing same-project/manual flags sync in place, new flags use the selected prefix, and original, prefixed, or custom-key collisions are caught before creation.
• Persists prefix/remap metadata in migration reports and keeps failure reporting keyed by the source LaunchDarkly flag key.
• Keeps non-interactive conflict handling strict while preserving explicit --feature-flag source,target mappings.

[vjfridge]

Left a few comments!

[vjfridge]

🤖[claude] Suggestion

The SIGINT partial-save handler is missing semverForcedClientKeys and jsonArrayWrappedKeys, both of which are accumulated during the migration. If the user interrupts with Ctrl+C, those fields won't appear in the saved JSON, so an xlsx export from the partial report will show SEMVER-forced and JSON-array-wrapped flags without any warning highlighting.

Consider adding them here to match the success-path shape:

semverForcedClientKeys: semverForcedClientKeys.length > 0 ? semverForcedClientKeys : undefined,
jsonArrayWrappedKeys: jsonArrayWrappedKeys.length > 0 ? jsonArrayWrappedKeys : undefined,

[vjfridge]

🤖[claude] Suggestion

After the user confirms a custom key, reservedDatadogKeys is never updated. A later flag in the same migration could pass the classifyDatadogKeyConflict check with the same key (since it's not yet reserved), only for the API creation to fail at runtime with a less clear error.

Consider adding the key to the reserved set immediately after confirmation, matching the pattern at the create path:

resolvedDdKey = customKey;
reservedDatadogKeys.add(customKey); // prevent a later flag from claiming the same key

[greghuels]

Oh good catch. I'll add a follow up PR