Normalize employeeid, unit, and category on write in compliance tables

[labkey-martyp]

Rationale

The ported PostgreSQL report procedures in ONPRC's compliance module wrapped every unit and category comparison in lower() to emulate the case-insensitive default collation the MS SQL originals relied on implicitly. All of those comparisons join employeeperunit against requirementspercategory, and the latter already canonicalizes unit and category on write through its trigger script — so employeeperunit, the only table in ehr_compliancedb without one, was the sole source of case drift. Normalizing on write instead removes the need for lower() downstream and keeps the joins indexable.

Related Pull Requests

• Migrate remaining ONPRC modules' SQL scripts to PostgreSQL onprcEHRModules#1859 — removes the lower() calls this change makes unnecessary. Merge this PR first, or those reports will silently drop rows whose unit or category differs only by case.

Changes

• Adds employeeperunit.js, normalizing employeeid, unit, and category against the lookups its schema metadata already declares.
• Adds sopdates.js, normalizing employeeid. sopid is excluded deliberately — its fk to sops is commented out in ehr_compliancedb.xml, and getLookupValue returns null for a column with no fk, which would reject every row.

Tasks 📍

• Claude Code Review
• Code Review

[bbimber]

@labkey-martyp and @labkey-jeckels: the pattern outlined here probably need to occur in more places. Are there ways to do this that are more efficiency and wont require repeating a lot of boilerplate code? Some thoughts:

• If we need to do this in query-specific trigger scripts, can the code be generalized into a central method that accepts the row object, key, lookup target, etc.?
• Could this jump into java, iterate ColumnInfos and infer what to do? For example, and string with a lookup to a table in EHR_Lookups probably should have enforcement.
• Perhaps something in the EHR trigger init() layer could let modules register names of target tables or target tables/field pairs, and any column with a FK to that table undergoes case-normalization?
• If we need JS files, could we use a JS schema customizer instead of per query?