[EngSys] The storage CI pipeline runs on every pull request

## Summary

`sdk/storage/ci.yml` declares no `paths` filter on its `trigger` block or its `pr` block, so the `cpp - storage - ci` pipeline starts on every pull request to `main`. Every other service pipeline in the repository filters by path.

## Motivation

A pull request that changes no storage file still starts the full storage build matrix across Windows, Linux, and macOS. Pull request 7339 changes only `doc/DistributedTracing.md` and files under `sdk/eventhubs/`, with no file under `sdk/storage/` and no file under `sdk/core/`, and it still reports 41 `cpp - storage - ci` checks. The storage pipeline also does not run storage tests on a pull request, and its own comment records "Not running tests on CI but only on LiveTest mode". The cost is build time with no added signal. A count of the `paths` keys puts storage alone at zero:

```
sdk/storage/ci.yml:0
sdk/eventhubs/ci.yml:2
sdk/core/ci.yml:2
sdk/keyvault/ci.yml:2
sdk/identity/ci.yml:2
sdk/tables/ci.yml:2
```

## Proposal

Add a `paths` block to the `trigger` block and to the `pr` block of `sdk/storage/ci.yml`, in the form the other service pipelines already use. The include list must hold `sdk/storage` and the shared paths that change a storage build, for example `eng/`, `cmake-modules/`, and `CMakeLists.txt`.

Make sure the present state is not deliberate before a change lands. An unfiltered storage pipeline can act as a wide canary that catches a core change which breaks a dependent package. A maintainer must confirm the intent, because the filter removes that coverage.

First read sdk/storage/ci.yml, then compare the trigger and pr path filters in sdk/eventhubs/ci.yml and sdk/core/ci.yml. Confirm with a maintainer whether the unfiltered pipeline is an intentional canary before changing it. Done means the intended storage and shared build paths are covered, while unrelated changes no longer start the pipeline.

Written by the indexing model from the issue text.