Add patient resources plugin

[admir-vicert]

PLUGIN-57 Patient resources

Patient Resources: an admin-curated library staff can share to a patient's portal

Adds a new plugin, extensions/patient-resources. Administrators curate a list of resource links; any staff member can open a patient's chart, search that list, pick one or several, adjust the note for the person in
front of them, and send. The patient finds them in the portal under My Resources, with the note and the date they were shared.

Ships with an empty library — nothing here is specific to any clinic.

Why

Most practices hand out the same handful of educational links repeatedly. Sent ad hoc, they get pasted into messages with typos and stale URLs, and there's no record of who was given what. Curating once means the
link a patient receives is the one the practice reviewed.

What ships

Three surfaces appear after install:

• Patient Resources — the library as a full page, in the provider menu (top group). Every staff member can open it; only administrators can change it.
• Resources — a button in the patient chart header that opens the picker for the open chart. All staff.
• My Resources — the patient's own list, in the portal menu, carrying a badge that counts resources they haven't opened yet.

Eight components: two Applications, one ActionButton, and five SimpleAPI route classes split so that curation needs no patient access (LibraryAPI reads Staff/StaffRole; ShareAPI reads Staff/Patient). No event
handlers and no scheduled work — everything happens in response to a click.

Two tables in the custom_data__patient_resources namespace: PatientResource (the catalog) and PatientResourceShare (one row per resource given to one patient).

All configuration is optional; the plugin works unconfigured.

Design decisions worth a reviewer's attention

Title and note behave in deliberately opposite ways. The portal reads the resource's current title, so fixing a typo fixes it for everyone who already received it. The note is the opposite — it's written for one
patient and stored on their share, so editing the library default changes only what the next send starts from. A title describes the resource; a note describes what this patient should do with it.

That asymmetry is only safe because a shared resource's link is frozen. Once anyone has received it, an edit is refused with a prompt to add a replacement and archive the original. The link is the identity of what a
patient was given, so with it immutable a title edit can only redescribe the same resource — never quietly swap it for a different one.

Delete vs. Withdraw is one slot, and which control appears is information. A resource nobody ever received offers Delete (archiving is the wrong record to leave for a typo or test data). Anything with share history
offers Withdraw — disabled with the reason on hover when every share is already withdrawn. The server refuses that case with a 409 too, so a direct request can't succeed at doing nothing. Hard delete is refused for
anything a patient received, including withdrawn shares: the foreign keys carry no cascade, so removing the catalog row would orphan the share records.

Withdrawing is louder than archiving. It marks every patient's copy withdrawn and archives the resource, and the portal says the item was withdrawn by their care team, with the date, rather than the row silently
vanishing from a list they'd already read. Requires typed confirmation. Restoring makes a resource offerable again but does not un-withdraw — hence the library marks such rows Withdrawn rather than Archived.

Blank config means "unset", not "off". A manifest variable with no value reaches the plugin as an empty string, indistinguishable from a missing key. An earlier version read blank as "switched off", which left every
fresh install with no administrator and no way to add a first resource. Blank now falls back to ADM; NONE switches curation off explicitly; an unrecognized value denies everyone and logs why, rather than being
quietly replaced with the default.

Both staff lists page at 25. The library adds a 25/50/100 per-page control, since a curator scanning a large library wants more rows than someone picking two in a modal. Selection in the picker survives a page
change, and anything selected but off-screen is named in the footer so a resource picked on page one can't go out unnoticed. One send carries at most 25; the API enforces it and the picker holds the same limit so
feedback arrives before the click.

The picker confirms, then closes itself. Sharing is the only thing that window does, so a clean send ends the task. The host protocol carries no notification of its own, so the notice lives on the page and the close
waits for it. The summary dialog stays only for a send that needs explaining — something already in the patient's list, or archived since the page was drawn. Sharing twice is not an error: the response distinguishes
newly sent, already shared, and since archived.

Security

• A patient can only read their own list. The portal endpoint takes no identifier of any kind — not a patient key, not a share id — and scopes from the session header alone. There is nothing in the request to tamper
  with.
• The admin app icon can't be hidden from non-admins — Canvas has no role scoping for application visibility. It renders read-only with an explanation, and every write endpoint re-checks permission server-side.
• Links validated on write and again on render. Only absolute http:///https://; javascript:, data:, protocol-relative and relative links refused. Re-checked at serialization so a row stored before a validation change
  can't render as a live link.
• rel="noopener noreferrer" plus a no-referrer policy on the portal page. This is a privacy control: without it a third-party health site receives the portal URL and learns a patient viewed a resource about a
  particular condition.
• No outbound HTTP. The plugin never fetches a resource; the browser opens the link.