Provisioning status board for allocation memberships

## Problem

When a user's allocation doesn't appear (e.g. cluster tooling shows "No Allocation", or the portal shows a membership but the cluster side is dead), there is no user or admin-facing signal explaining *why*. Diagnosis today requires SSH-ing to the host, grepping the SLURM association-mapper log, correlating a per-membership "connection refused" with one specific user, and checking the DB by hand.

Concrete case that exposed this: the cluster's `slurmrestd` was unreachable, so the SLURM associations were never written. The affected users could SSH in (their POSIX account had provisioned fine) but had no allocation on the cluster — with zero surfaced explanation.

A user's account-to-allocation connection has two independent provisioning dimensions (POSIX/SSH via the identity provisioner, and the SLURM association via the association-mapper) that fail separately, and neither surfaces its state anywhere a user or admin can see.

No files or tests are named. Start by tracing the identity provisioner and association-mapper paths described in the issue, then determine how the independent POSIX/SSH and SLURM association states should be surfaced to users and admins. Done means provisioning failures and their affected memberships have an understandable status signal.

Written by the indexing model from the issue text.