a member's terminal looks like the owner's

A new Linux account opens a shell with nothing: useradd copies /etc/skel, which on Ubuntu
is a bash rc, and the account's shell is zsh — so it got no prompt, no history, no
completion, no colour. "Their own account" should not mean a worse terminal than the
owner's.

src/servers/shell-skel/zshrc is the template, and scripts/starship.toml is reused rather
than copied: setup.sh already deploys it for the owner, so one file serves both audiences
and they cannot drift. Seeded by provisionOsAccount, which means the retry button applies
it to accounts that already exist — no delete-and-recreate.

The template depends on nothing but zsh. Starship, eza, nvim, bun, deno and cargo are each
used only if present, and every path is $HOME-relative — the owner's own .zshrc has three
absolute /home/pastilhas paths in it, which is exactly what a template must not inherit.
Without starship it falls back to a zsh prompt showing the same information, because a
shell that opens with a broken prompt reads as a broken machine.

Never overwrites: written only when the file is ABSENT. ~/.zshrc.local is sourced last and
never written, so there is somewhere to put your own config that no future template can
reach.

Three fixes found by running it:

- install -D creates missing parents but applies -o/-g only to the FILE, so ~/.config came
  out root:root — readable but not writable by its owner, which would have surfaced weeks
  later as one tool mysteriously failing. The parent is now created explicitly.
- useradd took its shell from process.env.SHELL, which under PM2 is whatever PM2 was
  launched from. A member's shell depended on how the server happened to be started. Now
  chosen from what is installed: zsh, else bash.
- the pty sidecar spawned ITS $SHELL for a member, not theirs. It now execs their passwd
  shell via sh -c, so the login shell in /etc/passwd is the one they get.

starship moves out of the light-profile skip. The light profile exists to serve a file
browser, a terminal and chat — the terminal is one of its three reasons to be, and it is
what every member gets. Leaving starship out meant the fallback prompt on exactly the
installs most likely to have members. oh-my-zsh, eza and lazygit stay full-only.

Verified in a real member shell: zsh from passwd, HISTFILE in their own home, eza-backed
ll, starship active, EDITOR=nvim, and an edit to .zshrc surviving a reprovision.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/api/users/provision-os.ts

@@ -1,6 +1,7 @@
 import { updateUser } from 'officerdb';
 import { OS_USERS_ENABLED, ensureOsUser } from '@@/os-user';
 import { provisionSshAccess } from '@@/os-user-ssh';
+import { seedShellConfig } from '@@/os-user-shell';
 import { provisionUserDirs } from '@@/data-path';
 
 // Giving an account its Linux side: the directory skeleton, the Linux user, the confinement, the keys.
@@ -67,10 +68,16 @@ export async function provisionOsAccount(params: {
     authorizedKey: params.inboundKey,
   });
 
+  // The shell configuration. Last because it is the only step whose failure leaves nothing broken — the
+  // account works, the keys work, the terminal opens; it just opens with zsh's bare defaults.
+  const shell = await seedShellConfig({ email: params.email, uid: account.uid, gid: account.gid });
+
   // The Linux account is recorded either way: it exists, it is confined, and a member's terminal can run as
   // it. Only the keys are missing, and that is what the error says.
   const sshPublicKey = ssh.ok ? ssh.publicKey : null;
   await updateUser(params.userId, { osUser: account.osUser, osSshPublicKey: sshPublicKey });
 
-  return { osUser: account.osUser, sshPublicKey, error: ssh.ok ? null : ssh.error };
+  // SSH first if both failed: no keys is the more consequential of the two.
+  const error = !ssh.ok ? ssh.error : !shell.ok ? shell.error : null;
+  return { osUser: account.osUser, sshPublicKey, error };
 }