Track native, mapped, and unsupported customization migration outcomes

## Telemetry need

We need aggregate telemetry that shows whether customization migration is improving over time—not only how many migration candidates were detected.

For each logical target harness, customization type, and bounded original source, report counts for:

- customizations already in the target's native location
- customizations working through compatibility mapping
- unsupported customizations

This should let us measure whether mapped and unsupported customizations decrease while native customizations increase.

## Proposed event shape

```ts
{
target,
customizationType,
source,
nativeCount,
mappedCount,
unsupportedCount
}
```

The event should remain aggregate and bounded. It must not include customization names, paths, IDs, descriptions, or content.

File customizations include agents, instructions, prompts, skills, and hooks from user and workspace sources. MCP servers should use their existing bounded source, delivery, compatibility, enablement, and applicability information. Disabled and out-of-scope MCP servers should be excluded.

## Performance requirement

Collecting the complete assessment must not delay chat request dispatch or repeatedly scan all customization types on every turn. Existing migration-hint discovery should remain gated by enabled migration categories. A complete telemetry assessment can be deferred and cached per logical target, workspace context, and inventory generation, with invalidation when customizations change.

## Non-goals

- migration action/result telemetry
- per-customization events
- changes to migration hint UX or migration candidate behavior

## Context

Follow-up to #333196. A prototype implementation and review discussion are available in #335391.