feat: add resident application status portal

docs/SERVICE_DIRECTORY_CONCEPT.md

@@ -124,3 +124,28 @@ and Forms Runtime are active. It resolves an exact published
 `<form-id>/<revision>`, validates launch values, and retains Service/binding
 provenance. Reduced installations still fail closed rather than simulating a
 submission in Portal.
+
+## Applicant Status Presentation
+
+Portal also presents Forms Runtime's bounded applicant-status projection at
+`/portal/status/:trackingId`. It does not persist a status, inspect a Form
+submission, or decide the disclosure policy. Forms Runtime resolves the tenant
+through the Core `application_status.projection` contract and remains
+authoritative for all access decisions.
+
+The page adapts to the configured grant:
+
+- authenticated-only access offers sign-in and then uses the applicant-bound
+  status endpoint;
+- email-link access accepts the linked email address and always reports the
+  same request outcome, whether or not it matched; a delivered link carries a
+  short-lived secret that can be resent and replaces its predecessor; and
+- permanent-link access loads from the high-entropy tracking URL without
+  authentication.
+
+All modes render only title, current lifecycle state, update time, receipt
+identifier, and the bounded public timeline supplied by Forms Runtime. Portal
+must not infer missing milestones or expose values, people, evidence, internal
+notes, or handoff details. A reload action re-fetches the authoritative
+projection. Missing, disabled, revoked, expired, or unauthorized grants share
+a non-enumerating unavailable state.