feat: allow enable to target individual pipeline files

## Problem

`ado-aw enable [PATH]` can only operate on a repository directory and always discovers every compiled pipeline under it. This makes it unsafe to register one new pipeline in a repository that also contains intentionally disabled or externally managed definitions: a full-repository `enable` may enable or create unrelated definitions.

Passing an individual agent source or compiled YAML as `PATH` does not narrow the operation. It is treated as a directory and fails before planning.

## Reproduction

With ado-aw 0.45.1 and a repository containing multiple compiled pipelines:

```text
ado-aw enable foo.yml --dry-run
```

or:

```text
ado-aw enable agents/foo.md --dry-run
```

Both fail on Windows with:

```text
Error: Failed to read directory:

Caused by:
The directory name is invalid. (os error 267)
```

Running against the repository root succeeds, but the plan includes every discovered fixture, including unrelated creates/enables.

## Expected behavior

Provide a supported way to target one or more individual pipeline fixtures, for example:

```text
ado-aw enable agents/foo.md
ado-aw enable foo.yml
ado-aw enable --include foo --include bar
```

The selected command should preserve repository context for remote/project inference while restricting create/enable operations to the requested fixture(s).

Ideally the same selection mechanism would be consistent across the lifecycle commands where broad discovery can be destructive (`enable`, `disable`, and `remove`).

## Workaround

Create the individual Azure DevOps definition directly with `az pipelines create --skip-first-run`, then verify its queue status, YAML path, and default branch separately.

Start by tracing the `ado-aw enable` command and its path-discovery and planning entry points, then compare how `disable` and `remove` select pipeline fixtures. Verify the behavior with the documented file and repository-root dry-run examples; done means individual paths or includes preserve repository context while limiting create, enable, disable, or remove operations to the selected fixtures.

Written by the indexing model from the issue text.