Separate ARM extension resource classification from tracked/proxy kind

## Problem

`getArmResourceKind` currently models `Tracked`, `Proxy`, `Extension`, and `BuiltIn` as mutually exclusive resource kinds.

In ARM, extension resource is an orthogonal concept from tracked/proxy. A resource can be both a tracked resource and an extension resource. Modeling extension as one value in the same enum as tracked/proxy loses that distinction and can make downstream resource analysis ambiguous or incorrect.

The broader `ArmResourceKind` type also contains `Virtual`, `Custom`, and `Generic`, but `getArmResourceKind` currently only returns `Tracked`, `Proxy`, `Extension`, `BuiltIn`, or `undefined`.

## Suggested direction

Separate resource classification into independent dimensions, for example:

- shape/base kind: tracked, proxy, built-in, custom/generic/etc.
- scope/placement kind: extension vs non-extension

This should let a resource be represented as both tracked/proxy and extension when the ARM path/model semantics require it.

## Related context

This came up while reviewing the `resolveArmResources` design and implementation. Resource identity and scope detection should not depend on an enum where extension competes with tracked/proxy.