Clarify the audience split between protocol-internals and dApp-developer skills

The node-architecture skills — `midnight-storage`, `midnight-consensus`, `midnight-cryptography`, `midnight-p2p-networking`, `midnight-rpc`, `midnight-transactions`, `midnight-onchain-logic` — are clear and well-diagrammed, and there's a real audience for them. This is a suggestion about *organization*, not a request to remove anything.

**Observation.** These seven skills describe protocol internals (ParityDB, twoxhash, GRANDPA/AURA, libp2p transport, trie commitments). That's largely node-operator / protocol-curiosity territory rather than day-to-day dApp-building, yet they sit in the same flat catalog as the build-focused skills — about 7 of 31 entries. A dApp developer scanning the router may not have an easy way to tell "read this to build" from "read this to understand the chain."

**Why it matters.** The repo's headline is developer support for building privacy-preserving dApps. A clearer split helps a builder find the build path quickly, and lets the protocol content stand on its own for the audience that wants it.

**Suggested direction (options):**

- Group the catalog into explicit tracks — e.g. "Build a dApp" vs "Protocol internals" — in the router (`midnightskill/SKILL.md`) and README, which `skills.json` categories could already express.
- Or fold the deeper protocol material behind a single "How Midnight works under the hood" entry point.

Purely a curation call — the content itself is solid.

Read midnightskill/SKILL.md, README, and the skills.json categories to understand the current catalog and available grouping. Decide whether explicit tracks or a protocol-internals entry point best separates the audiences, then update the affected documentation so dApp builders can find the build path and protocol content remains discoverable.

Written by the indexing model from the issue text.