provisioning: re-assert the acl mask, last

on a fresh server an Admin granted files, chat and terminal reached none of
them. the grants were right, the linux account existed, the named acl entries
were on the home — and the file browser still raised EACCES.

a posix acl mask is not independent of the mode bits. chmod recomputes it from
the GROUP bits, so a directory closed to 700 gets `mask::---`, which clamps
every named entry to nothing. the platform's grant survived as
`user:pastilhas:rwx #effective:---`: present, correct-looking, and inert. it
reads as a working acl in every place anyone thought to check.

ensureOsUser already knows this and orders itself correctly — chmod, then
setfacl, with a comment saying why. verified that order is right by running
both ways on the affected host: chmod-then-setfacl gives mask::rwx,
setfacl-then-chmod gives mask::---.

what it cannot account for is the steps AFTER it, each of which creates a
directory and then closes it: .ssh at 700 from the key setup, .config and
.local from the claude installer. each inherits the default acl at creation
and clamps its own mask a moment later. the correlation on the live host was
exact — every 770 directory had mask::rwx and every 700 one had mask::---.

so the mask is re-asserted at the very end of provisionOsAccount, recursively,
and nothing else is touched: the named entries were never wrong, and
re-granting them here would hide it if they ever were.

non-fatal if it fails, like every other side effect in that function. but it
is the difference between an account that works and one that only appears to.

repaired on the affected server by hand first, and confirmed: home readable by
the service user, zero `effective:---` entries left under it.

src/servers/os-user.ts

@@ -545,6 +545,49 @@ export async function confineUserTree(params: {
 const OWNER_HOME_PRIVATE = ['.claude', '.pm2', '.config', '.npm', '.opencode', '.cache', '.tmux'];
 const OWNER_HOME_PRIVATE_NESTED = ['.local/share', '.local/state'];
 
+/**
+ * The exact command, split out so a test can assert it without root or an acl-capable filesystem.
+ *
+ * `-R` because the same clamp happens to every subdirectory created and closed after the original grant,
+ * not just to the home itself. Only the mask — the named entries were never the problem.
+ */
+export const maskArgvFor = (home: string): string[] => [
+  'sudo',
+  '-n',
+  'setfacl',
+  '-R',
+  '-m',
+  'm::rwx',
+  '-m',
+  'd:m::rwx',
+  home,
+];
+
+/**
+ * Re-assert the ACL mask across a member's home. **Must run after every other provisioning step.**
+ *
+ * ── The failure this exists for ──
+ *
+ * A POSIX ACL mask is not independent of the mode bits: `chmod` recomputes it from the GROUP bits, and a
+ * directory chmod'd to 700 gets `mask::---`, which clamps every named entry to nothing. The platform's
+ * grant then reads `user:pastilhas:rwx #effective:---` — present, and meaningless.
+ *
+ * `ensureOsUser` already knows this and orders itself correctly (chmod, then setfacl). What it cannot
+ * account for is the steps that come AFTER it, each of which creates a directory and then closes it:
+ * `.ssh` at 700 from the key setup, `.config` and `.local` from the claude installer. Each one inherits
+ * the default ACL at creation and then clamps its own mask a moment later.
+ *
+ * Observed on a fresh server, 2026-08-19: an Admin holding `files`, `chat` and `terminal` reached none of
+ * them. The file browser's `readdir` raised EACCES on a home whose ACL said it could read it, and the
+ * grant looked correct in every place anyone thought to check.
+ *
+ * Only the mask is touched. The named entries are already right — they were never the problem.
+ */
+export async function reassertHomeMask(home: string): Promise<{ ok: boolean; error?: string }> {
+  const done = await run(maskArgvFor(home));
+  return done.ok ? { ok: true } : { ok: false, error: `could not re-assert ACL mask on ${home}: ${done.out}` };
+}
+
 /**
  * Close the owner's own dotfiles to the accounts this platform hands shells to.
  *