fix: Replace raw in operator checks with keyof-validated type guards

[Who-is-PS]

Description

Replaces raw 'prop' in obj checks with keyof-validated alternatives across 6 components to prevent a class of bugs where TypeScript silently accepts invalid property name strings in in expressions.

This is a COE action item AWSUI-59006 from the property filter bug (YpPBAPz2BrqF) where a type change during refactoring silently broke a 'propertyKey' in newToken check because TypeScript doesn't validate the in operator — 'banana' in obj compiles without error.

Changes:

• Added isStackableItem() and isRefObject() type guards to flashbar/utils.ts
• Updated collapsible-flashbar.tsx to use isStackableItem() (2 checks) and isRefObject() (1 check)
• Updated non-collapsible-flashbar.tsx to use isRefObject() (1 check)
• Updated mixed-line-bar-chart/utils.ts to use keyof in isYThreshold() and isXThreshold() (2 checks)
• Updated side-navigation/util.tsx to use inline keyof variables for 'href' and 'items' checks (2 checks)
• Updated top-navigation/parts/utility.tsx to use inline keyof for 'items' check (1 check)
• Updated button-dropdown/internal.tsx to use inline keyof for 'items' and 'badge' checks (2 checks)
• Updated button-group/item-element.tsx to use inline keyof for 'popoverFeedback' check (1 check)

12 checks across 7 files, 6 components. No behavioral changes. Pure refactor for type safety.

Related links, issue #, if available: AWSUI-59006 and Tech Proposal. (k9wvA3eNMiZ9).

How has this been tested?

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.43%. Comparing base (b8108b4) to head (c98b616).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4306   +/-   ##
=======================================
  Coverage   97.43%   97.43%           
=======================================
  Files         897      897           
  Lines       26350    26358    +8     
  Branches     9516     9516           
=======================================
+ Hits        25675    25683    +8     
+ Misses        669      632   -37     
- Partials        6       43   +37     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[georgylobko]

In overall I'm not following what is fundamentally different in this function after refactoring. Could you add a u tests that fails before the refactoring and passes after?

[georgylobko]

the type is optional

Suggested change

	const isGroup = (option: AutosuggestItem) => option.type === 'parent';
	const isGroup = (option: AutosuggestItem) => option?.type === 'parent';

[Who-is-PS]

Updated with optional chaining

[georgylobko]

Suggested change

	const useEntered = option.type === 'use-entered';
	const useEntered = option?.type === 'use-entered';

[georgylobko]

And the same for isParent and isChild

[Who-is-PS]

Done, applied ?. to all three.

[georgylobko]

Should the ref argument be typed as any? When you call this function, you don't know the type of ref yet - that's exactly what this function is supposed to check

[Who-is-PS]

Changed to unknown instead of any since we already do !== null && typeof ref === 'object' runtime checks inside.

[georgylobko]

I'm not following what is fundamentally different in this function after refactoring. Could you add a u test that fails before the refactoring and passes after?

[Who-is-PS]

The runtime behavior is identical — no unit test can distinguish before/after because both produce the same output for every input.

The difference is at compile time. If someone renames options to items on OptionGroup:

• Before: 'options' in option — compiles fine, silently returns false for all groups (the exact COE bug pattern)
• After: const key: keyof OptionGroup = 'options' — fails to compile: Type '"options"' is not assignable to type '"items" | ...'