Document how validatePrefix composes the key prefix

[justin-masse]

What

A doc comment on validatePrefix. No behaviour change.

Why

The SDK's own SPLITIO segment is appended to the value you supply, so a prefix of myApp produces myApp.SPLITIO.split.<name> — the custom part comes first. That ordering is easy to get backwards, and SPLITIO isn't implied, so passing it explicitly produces SPLITIO.SPLITIO.split.<name>.

We lost real time to this. A producer and a consumer that disagree on the prefix don't error — they simply never find each other's keys, and every evaluation returns control. There's no log line and no exception, so there's nothing to search for.

Worth saying out loud that the ordering seems genuinely easy to misremember: it was described to us in writing by Harness as SPLITIO.<custom>.<key>, which is the reverse of what this function does. Documenting it at the source seemed better than filing a docs ticket.

I considered warning when the supplied prefix is already SPLITIO, but validatePrefix has no logger in scope and changing the composition would silently move existing deployments' keys, so a comment seemed like the right scope.

How did you test this code?

• jest src/storages/__tests__/KeyBuilder.spec.ts — 9/9 passing.
• eslint src --ext .js,.ts — clean.

[justin-masse]

Folded into #527 — both changes touch the same Node.js pluggable storage path, so one PR is less overhead to review. Closing this one; the commit is unchanged over there.