Remove network-level fields (`bppId`, `bppUri`) in `Catalog` schema and move them into a context object

The `Catalog` schema currently defines the following fields:

```yaml
"beckn:bppId":
type: string
description: BPP (Beckn Protocol Provider) identifier that publishes this catalog
example: "bpp.example.com"

"beckn:bppUri":
type: string
format: uri
description: BPP (Beckn Protocol Provider) URI endpoint
example: "https://bpp.example.com"
```

This appears to introduce a conceptual overlap between **network-level addressability** and **business-level domain modeling**.

### Issue

* `bppId` and `bppUri` are **network participant–level identifiers**, used for routing, authentication, and protocol-level interactions.
* A `Catalog` is a **business (provider-level) construct**, representing offerings, items, and commercial intent, not network addressability.
* Beckn already has a well-defined mechanism for carrying network participant metadata via the **`context` header**, which was explicitly designed for this purpose.

Embedding `bppId` and `bppUri` inside the `Catalog` schema:

* Duplicates information already present in `context`
* Blurs the separation between protocol metadata and business payloads
* Creates ambiguity about the authoritative source of network identity
* Makes catalogs less portable across networks and execution contexts

### Why this matters

One of Beckn's core design principles is **clear separation of concerns**:

* `context` → who is talking to whom on the network
* payload schemas → what business object is being exchanged

Mixing these layers increases cognitive load for implementers and complicates schema evolution, especially in multi-network and federated environments.

### Suggested direction

* Remove `bppId` and `bppUri` from the `Catalog` schema
* Rely on `context.bpp_id` and `context.bpp_uri` as the single source of truth for network-level addressability
* Keep `Catalog` strictly scoped to provider/business semantics

This aligns better with Beckn's architectural intent and keeps schemas clean, composable, and future-proof.