Support non-ASCII names in CLI pull and deploy

On a pull, a workflow or step name becomes three things at once: a directory on disk, the key in the project file, and the value a deploy uses to decide whether a job it is looking at is one it already knows. All three come out of slugify() in packages/project/src/util/slugify.ts, which is ASCII-only, so a name in a non-Latin script collapses to an empty string and two such names collapse to the same one.

That part is #1388. What I did not expect is that the three jobs want different answers.

A directory name has to survive a filesystem, and macOS folds harder than any rule we have: Straße and Strasse are one file, so are Notification pasted from a PDF and Notification typed normally. Two workflows can silently become one directory, and a collision check keyed off our own slug cannot see it.

A key in the project file has to stay stable across a rename. mergeSpecIntoState in packages/deploy reads a state key missing from the spec as a deletion and mints a fresh id for a spec key it has not seen, so changing the derivation is a delete-and-recreate for everything already synced. Past runs still render, because Lightning serves them from snapshots, but they stop being retriable: the rerun button checks the live job and finds nothing there.

And packages/lexicon/portability.d.ts already separates the ideas: id is "the primary internal identifier for a Workflow (not a UUID)", name is a label that "can be used to generate an internal id". In practice the id is derived from the name on every pull rather than recorded once. Whether that should change is the decision the rest hangs off, and I have no view I would defend.

The demand is real. In OpenFn/flujos-rd the same authors wrote Flujo 2: Finalización y distribución de evaluaciones de SIUBEN as a workflow name and Simula pre-categorizacion as a step name in the same spec, because workflow names have never had a charset rule and step names have had one since 2022.

I have not worked out what an acceptable migration looks like for repos already on disk, or whether this can land in pieces. You mentioned you were interested in this side, so I would rather you took the design than have me guess at it.

#1512, #1513 and #1514 came out of the same reading and are independent - they all break today with plain ASCII names.