All Providers to be made Addressable on Beckn

### Summary
This proposal introduces a structural change to the Beckn addressing architecture: **all providers MUST be individually addressable via the registry**, not just the BPPs they are onboarded through.

This evolves the network mental model from *platform-addressability* to *provider-addressability*, while retaining backward compatibility in lookup semantics.

---

### Problem Statement
Currently, the registry only maintains entries for **BPPs (subscriberId = bppId)**. Providers SHOULD be implicitly reachable *through* their BPPs but are not first-class addressable entities.

---

### Proposed Change

#### 1. Provider-Level Registry Entries
- **All providers MUST be registered as first-class records in the registry.**
- Each provider will have:
- `subscriberId = provider.id`
- `role = BPP` (Retained for backward compatibility)

#### 2. Endpoint Resolution Logic
- If a provider is **Self-hosted (e.g., Shopify storefront)** → its own URL is registered.
- If a provider is **Onboarded via an aggregator** → aggregator’s URL is registered against the provider.

#### 3. Key resolution logic
- If a provider is self-hosted (e.g., Shopify storefront), then its own public key is registered.
- If a provider is onboarded via an aggregator** there are two options,
- The aggregator's key is registered, or
- The provider's own key is registered
- Note: The key MUST belong to the entity that will take liability for the fulfillment of the established contract terms.

---

### Runtime Flow Changes

#### Discovery Phase (unchanged structurally)
- BAP calls `discover` on the Discovery Service
- BAP receives `on_discover` response with array of items of type `Catalog`. Each `Catalog` item in the array has a property called `provider` of type `Provider` which contains its identifier at `catalog.provider.id`.

#### Lookup Phase (updated usage)
- BAP calls `lookup` on the Registry: with `subscriberId` set with value of `catalog.provider.id` obtained from the `on_discover` response
- Registry returns records with properties `subscriberId` and `apiUrl`
- BAP sets `context.bppId` with value `subscriberId` and `context.bppUrl` with value of `apiUrl`
- In the `order.participants` array, where the participant is of type `Provider`, the value of `order.participants[].id` MUST be set to the same value as the `context.bppId`.
- Interaction continues as per existing protocol semantics.

---

### Key Observations

- **Registry lookup mechanism remains unchanged**
- Only **cardinality of entries increases**
- **No change to API contracts or verb semantics**
- **Backward compatible** with existing flows

Enables:
- Fine-grained routing
- Provider-level observability
- Better alignment between semantic and network identifiers

---

### Design Implications

| Aspect | Before | After |
|------|--------|------|
| Registry entries | Only BPPs | All Providers |
| Addressability | Platform-level | Provider-level |
| subscriberId meaning | BPP identity | Provider identity |
| Routing | Indirect via BPP | Direct via provider |
| Catalog → Network mapping | Loose | Strong |

---

### Rationale

This change aligns with Beckn’s core principle of **unambiguous, machine-resolvable contracts**:

- A `provider.id` in a catalog is no longer just a semantic identifier — it becomes a **network-resolvable endpoint reference**.
- Eliminates ambiguity between **who is offering value** and **who is addressable on the network**.
- Improves **interoperability and composability** across heterogeneous provider infrastructures.
---

### Conclusion

This is a minimal but high-leverage change:
- No protocol flow changes
- No API redesign
- Significant improvement in **addressability, clarity, and extensibility**

Effectively, this moves Beckn closer to a true **Internet of Value Exchange**, where every economic actor is a **first-class, addressable node**.

---