Build: parse workspace ids at one boundary (injective scheme) #64

Question

Build: derive workspace ids at one parse boundary, with an injective scheme.

Graduated from #55, which decided the scheme, the layout, and that ref validation folds in here. This ticket implements it; it decides nothing.

The scheme

<repo-slug>-<branch-slug>-<syl3>        target cap 38; hard ceiling 48 (devpod)

  repo    never truncated below 20 chars — it is the readable context
  branch  absorbs all truncation; segment-aware (drop middle /-segments first)
  syl3    6 chars: 3 consonant-vowel syllables, 18 bits of sha256 over the
          UNSANITIZED (owner, repo, ref) triple. NEVER truncated.

Encoding: 16 consonants (bdfghjklmnprstvz) × 4 vowels (aeio) = 64 combos = exactly 6 bits per syllable. Pin both tables with a test — they must stay byte-identical across the Rust port or every id changes.

Identity is in syl3, legibility in the slug. Only the slug is ever truncated, so truncation cannot cause a collision.

The slice

• One parsed type (WorkspaceId or equivalent) with a single constructor taking (owner, repo, ref). It replaces both sanitize_workspace_id (dl.py:388) and _sanitize_branch_dir (workspace_clone.py:36), and is the single source for the devpod workspace id and the clone-dir leaf (get_workspace_path, workspace_clone.py:78).
• Fold in ref validation. _validate_ref (workspace_clone.py:86) returns a naked str carrying no evidence, which is structurally why get_workspace_path:78 was left unguarded. Validate once at the constructor and return a type that proves it; the raise-vs-coerce split in one module collapses to one response to bad input.
• Fix the truncation guard hole. dl.py:447-449: max_branch = 48 - len(repo_name) - 1 goes ≤ 0 for a repo name ≥ 47 chars, so 0 < max_branch is false and truncation is skipped entirely — a 47-char repo currently yields an 80-char id.
• Delete the second derivation. _ → - at dl.py:445 vs _ → deleted at dl.py:469 (my_repo → my-repo vs myrepo). One derivation only.
• Keep spec_to_workspace_id's existing behavior for path specs and already-resolved ids — the change is to the owner/repo/branch path.

Acceptance

These pin the defects #55 verified, so they belong in the test suite:

• blooop/devlaunch@feature/auth and blooop/devlaunch@feature-auth derive different ids.
• All five of feature/auth, feature-auth, feature auth, feature+auth, feature:auth derive five distinct ids.
• A 47-char repo name yields an id ≤ 38 chars (currently 80).
• Two branches sharing a 30-char prefix derive different ids.
• Every id is ≤ 38 chars and the repo slug is intact for any repo name ≤ 20 chars.
• A ref failing validation is rejected at the constructor, on every path — including the one get_workspace_path uses.

No migration in this ticket — that is its own slice, and it is blocked on this one.