Using catalog/publish in generic-devkit is fragile and undocumented

[nirmay]

Problem

Getting catalog/publish working end-to-end in generic-devkit required a long series of trial-and-error fixes, none of which were caught by existing docs, config, or validation:

• The devkit's own shipped config (generic-bpp.yaml) had stale/incorrect keys (keyID, domain, indexSchemaURL) left over from an earlier version of the plugin, causing a "subscriberId is required" runtime error with no indication of what was wrong or where to look.
• The output folder/path naming used by the plugin (/catalog, dedi/) didn't match what was actually documented or expected, and had to be corrected multiple times (/catalog → /beckn, dedi/ → index/, flat catalogs/ → catalogs/changes/).
• There is no way to tell, from the devkit alone, whether the generated catalog index and manifest are actually reachable at their public URLs — this only surfaces if you separately think to expose the output directory (e.g. via Caddy/ngrok) and test it by hand.
• Wiring schema validation for incoming catalogs required discovering, through trial and error, that the request body needed to be reshaped to match beckn.yaml's real envelope (context/message/publishDirectives) — nothing in the devkit or its docs pointed this out ahead of time.
• After removing an unrelated crawler feature, the BAP failed to start with a low-level invalid module: catalogPull error, because the devkit's config still referenced a module type that no longer existed — nothing validates devkit config against what the running binary actually supports.
• The node-manifest "does this publisher's index show up in DeDi" check silently produced misleading warnings for a long time: any failure to fetch/parse the manifest (including a subscriber-ID format mismatch) was indistinguishable from "the index genuinely isn't linked yet," so a correctly-linked index still reported as missing.
• The DeDi subscriber identity model itself is confusing in this context: the plain Beckn subscriberId (used for keyset/signing) and the DeDi registry's own namespace/registry/recordName path are two different identifiers that look similar enough to be mixed up, and the devkit gives no guidance on which one goes where.

Net effect: there's no reliable, self-contained way for someone bringing up generic-devkit to get catalog/publish working without deep knowledge of the underlying plugin's internals and recent history.