fix: stack header emoji respects allowedDestroyTypes

[igraves]

Problem

Removals whose resource type is listed in allowedDestroyTypes are correctly excluded from destructiveChanges — they don't fail the job and don't appear in the "Destructive Changes" warning banner. But the per-stack header emoji still keys on the raw removal count:

private getEmoji(changes: ChangeDetails): string {
  if (changes.destructiveChanges.length || changes.removedResources) {
    return ':x:';

So routine, by-design churn — e.g. the AWS::ApiGateway::Deployment roll CDK performs on every REST API change (new hash-suffixed logical ID + removal of the old one) — paints the stack header ❌ even though there's no warning banner and the job passes. Reviewers see a red X with nothing destructive reported, which reads as inconsistent.

Fix

Key :x: on the filtered destructiveChanges only. Removals of allowed types render :yellow_circle: like other routine updates. Any non-allowed removal still lands in destructiveChanges (the early-return in StackDiff.evaluateDiff only skips allowed types), so it keeps the ❌.

Tests

Two new cases in stage-processor.test.ts:

• removal of a type in allowedDestroyTypes → destructiveChanges == 0, comment contains :yellow_circle: and not :x:
• same removal with empty allowedDestroyTypes → destructiveChanges == 1, comment contains :x:

npx projen build run; dist/ included per repo convention.

🤖 Generated with Claude Code

[igraves]

@corymhall Feel free to take this or not. It was an issue I bumped into when visually filtering destructive changes from updates and an artifact of how CDK considers certain updates in an immutable context.