feat(telemetry): tag execution events with source_layer="comfyui"

[deepme987]

Summary

Every event emitted from src/main/lib/executionTap.ts (the 6 comfy.desktop.execution.* event families) originates in the ComfyUI Python subprocess — executionTap exists purely to parse proc.stdout / proc.stderr. Today they all land in PostHog without any way to filter engine-origin from shell-origin.

This PR adds source_layer: 'comfyui' to the shared baseContext, so the tag is present on every emission with zero risk of any event family being missed.

PostHog filter for triage becomes:

event = 'comfy.desktop.execution.error'
  AND properties.source_layer = 'comfyui'

Why a property and not a new event-name namespace?

Considered renaming to comfy.desktop.comfyui.execution.* (matches the existing comfy.desktop.comfyui.boot_started / boot_log / exited namespace). Decided against for now because:

• Every existing dashboard, funnel, and saved insight filters on the current event names — rename breaks all of them simultaneously
• The 1-SDK-in-main consolidation (fix(telemetry): cap app-update event volume + disable telemetry in unpackaged dev #789) is still rolling out; stacking event-name churn on top makes regression triage harder
• Filtering by property gets the same triage outcome with no migration window

If we later want the cleaner namespace, the property tag makes a backfill migration easy.

Scope

Covers all 6 emissions in executionTap.ts:

• comfy.desktop.execution.started
• comfy.desktop.execution.completed
• comfy.desktop.execution.first_completed
• comfy.desktop.execution.error (validation path)
• comfy.desktop.execution.error (traceback path)
• comfy.desktop.execution.session_summary

Diff is 2 files, +34/-1.

Test plan

• New test asserts source_layer === 'comfyui' on every event family this tap emits (executionTap.test.ts)
• All 11 existing executionTap tests still green
• Full unit suite: 1867/1867 pass
• pnpm typecheck clean
• pnpm lint clean
• After merge: confirm in PostHog that properties.source_layer is populated on new events and the triage filter above returns expected volume

Follow-ups (not in this PR)

• Investigate the error_bucket = 'other' win32 cluster — 1,454 users producing ~21.5 errors/user each in the last 24h suggests a single common failure pattern that isn't being classified. Worth a sample-and-fingerprint pass.