Make the CLI agree on how a name becomes a key

Two ways of turning a name into a key, and they disagree on whitespace. kit collapses runs of whitespace (hyphenate, packages/deploy/src/utils.ts:7). Lightning replaces one space at a time (export_utils.ex:61). So Transform data with two spaces is Transform-data on one side and Transform--data on the other, and a tab does the same. Single spaces agree, so most projects are fine.

When the keys diverge, mergeSpecIntoState reads the state key missing from the spec as a deletion and mints a fresh id for the spec key it has not seen (stateTransform.ts:90). The delete and the create go out in the same request with nothing to say they are the same job.

History survives that, since run pages render each step from its snapshot. Retry does not. The rerun button checks the live job assoc, which is now nil, so it greys out with "this step has been deleted". The bulk picker lists live jobs and matches them against ids from old steps, so it offers nothing. WorkOrders.retry/3 fails a check constraint if you reach it, and cron cursors are nulled.

A diverging workflow name is worse. toProjectPayload filters deleted workflows out of the payload, so no delete is sent and the old workflow and everything under it is orphaned on the server.

Two more of the same shape. Jobs and triggers share one id namespace in from-app-state.ts, so a job named Webhook collides with the trigger, its .js is never written, and the next deploy pushes the literal ./webhook.js as that job's body. And macOS folds harder than any rule we have: Straße and Strasse are one file, so two workflows can silently become one directory.

All of it is a name becoming an identifier in several places by several rules, none of which matches the filesystem. Patching them separately probably does not converge, so this likely belongs with #1515.

Came up while investigating lightning#4577.