NFH-007: revert keyId to v1 pipe-separated format

## Problem

The current draft of NFH-007 (Authentication and Trust) defines the Beckn HTTP Signature `keyId` using a path-based (`namespace/registry/record`) format with an implicit/explicit two-format model. This is a change from the long-standing pipe-separated format:

```
{subscriber_id}|{unique_key_id}|{algorithm}
```

Example: `example-bap.beckn.io|ae3ea24b-cfec-495e-81f8-044aaef164ac|ed25519`

Our view is that the path-based format brings no benefit over the pipe-separated form, while breaking every current implementation and registry integration that parses and issues keyIds in the existing format. Changing the wire format is a cost we should only take on for a concrete gain, and there is none here.

## Proposal

Revert `keyId` in NFH-007 to the pipe-separated format as the single normative definition, and remove the implicit/explicit two-format model entirely. `keyId` becomes exactly three pipe-separated components: `subscriber_id`, `unique_key_id`, and `algorithm`.

Signing-string construction, Ed25519 requirements, and all other normative text remain unchanged.

## Related

- [beckn-onix#751](https://github.com/beckn/beckn-onix/issues/751) — implementation discussion that surfaced this format question. Implementations should conform to the format defined in NFH-007.