Introduce LRU cache implementation in cache package

### Is your feature request related to a problem? Please describe.

The current `MemoryCacheStore` implementation in the `cache` package is backed by `sync.Map` with no upper bound on the number of entries. In the helm provider, full `*chart.Chart` objects (which can be several megabytes each) are cached without any eviction policy, leading to unbounded memory growth under sustained use.

This was identified as a future phase in [Issue #130](https://github.com/kubevela/pkg/issues/130).

### Describe the solution you'd like

Add an `LRUCache` implementation to the existing `cache` package, backed by [`hashicorp/golang-lru`](https://github.com/hashicorp/golang-lru), that:

- Satisfies the existing `Cache[K comparable]` interface.
- Accepts a configurable **max size** (maximum number of entries) in its constructor.
- Supports **per-entry TTL** with background expiration (consistent with `MemoryCacheStore` behavior).
- Evicts the **least-recently-used** entry when the cache reaches capacity.
- Is thread-safe (delegated by `hashicorp/golang-lru`).

### How does this relate to the existing cache package?

The `Cache` interface defined in `cache/cache.go` already provides the abstraction needed. This change only adds a new implementation alongside `MemoryCacheStore`:

```
cache/
├── cache.go # Cache interface (unchanged)
├── map.go # MemoryCacheStore (existing)
└── lru.go # LRUCache (new)
```

Consumers that currently declare fields as `*MemoryCacheStore` can switch to the `Cache[K]` interface and select the appropriate backend at construction time.

### Additional context

- The `hashicorp/golang-lru` library should be added as a dependency in `go.mod`.
- The existing tests in `cache/map_test.go` serve as a pattern for the new `cache/lru_test.go`.
- Callers in `kubevela/kubevela` that currently use the inline `MemoryCacheStore` (e.g., `pkg/utils/cache.go`) can migrate to this bounded implementation once available.