fix(DotPropertiesService): handle boolean values returned by config endpoint for feature flags

[rjvelazco]

Summary

• Fixes DotPropertiesService.getFeatureFlag() to correctly handle native JSON boolean values (true/false) returned by /api/v1/configuration/config for FEATURE_FLAG_* keys — previously only string "true" was handled, causing feature flags to silently evaluate as false and hiding the Style Editor tab in the Content Type Builder
• Updates getKey() return type from Observable<string> to Observable<string | boolean> to match the actual API contract
• Fixes downstream TypeScript narrowing errors in DotWysiwygPluginService and DotContainersService caused by the widened return type

Test plan

• yarn nx test data-access passes including the two new boolean true/false unit test cases
• Open the Content Type Builder and verify the Style Editor form tab is visible when FEATURE_FLAG_UVE_STYLE_EDITOR_FOR_TRADITIONAL_PAGES is enabled on the backend
• Verify feature flags that return string "true" / "false" continue to work correctly (backward compatibility)

Fixes #35331

Video

video.mov

🤖 Generated with Claude Code

[claude]

Claude finished @rjvelazco's task in 1m 56s —— View job

---

Code Review

• Read changed files
• Analyze logic and edge cases
• Post findings

---

The core fix is correct — getFeatureFlag and getFeatureFlags now properly handle native JSON booleans. The type widening and downstream type guards are sound. However, there are three callers of getKey/getKeys that were not updated and now have latent bugs if the API starts returning booleans for their keys:

1. dot-block-editor.component.ts:418 — silent wrong result

// showVideoThumbnail$()
.pipe(map((property = 'true') => property === 'true' || property === 'NOT_FOUND'));

property is now string | boolean. If the API ever returns native true for SHOW_VIDEO_THUMBNAIL, both comparisons are false and the method returns false even though the feature is on. The = 'true' default parameter in a map() callback has no effect (defaults only apply when the value is undefined). Fix this →

2. dot-custom-event-handler.service.ts:61 — flag silently disabled

const contentEditorFeatureFlag =
    response[FeaturedFlags.FEATURE_FLAG_CONTENT_EDITOR2_ENABLED] === 'true';

getKeys return type is now Record<string, string | boolean>. If the API returns native true, === 'true' is false, so the content editor 2 feature flag is silently disabled. Fix this →

3. field-properties.service.ts:50 — possibly wrong render mode type

map((value) => (value === FEATURE_FLAG_NOT_FOUND ? DotRenderModes.IFRAME : value))

value is now string | boolean. The else branch passes value through unchanged, meaning the signal could receive a boolean when the expected type is DotRenderModes. Whether TypeScript catches this depends on how $newRenderModeDefault is typed. Functionally, if FEATURE_FLAG_CONTENT_EDITOR2_RENDER_MODE_DEFAULT is a string key (not a feature flag key), this is lower risk — but it's still unguarded. Fix this →

---

Design note: widening getKey() to Observable<string | boolean> for all keys (not just feature flag keys) is a leaky abstraction — callers requesting genuinely string-only config values (like WYSIWYG_IMAGE_URL_PATTERN or DEFAULT_CONTAINER) now have to add defensive guards. This PR correctly adds those guards in the two files it touches, but misses the three above. Whether to split getKey into typed variants is a larger refactor, but the three missed callsites should be fixed before this merges.