Scope ONPRC billing run deletion to the current container

[labkey-martyp]

Rationale

ONPRC_BillingManager.deleteBillingRuns built SimpleFilters over the raw onprc_billing tables (invoicedItems, invoiceRuns, miscCharges) from request-supplied primary keys with no container predicate, and the method received no Container. Since DeleteBillingPeriodAction's permission check is evaluated only against the current folder, a billing admin in one folder could delete or detach billing rows belonging to any other folder by POSTing arbitrary object IDs - a cross-container horizontal privilege-escalation bug. This change confines every operation to the caller's folder. This is the 26.3 port of #1759 (originally against release25.7-SNAPSHOT).

Related Pull Requests

• Scope ONPRC billing run deletion to the current container #1759 (original, against release25.7-SNAPSHOT)

Changes

• Add a Container parameter to deleteBillingRuns and pass getContainer() from both DeleteBillingPeriodAction call sites.
• Add integration test ONPRC_BillingManager.TestCase asserting a delete from one container cannot affect another, registered in ONPRC_BillingModule.getIntegrationTests().
• Drop two unused row-count locals from the Table.delete calls.

Container filters added on

All tables are in the onprc_billing schema:

• invoiceRuns - container filter on the PK->run-id lookup and on the final delete.
• invoicedItems - the preview read and the delete both carry a direct container filter (SimpleFilter.createContainerFilter) plus an invoiceId restriction to the container-scoped run ids.
• miscCharges - the read and the detaching Table.update are keyed off container-authorized run ids only; intentionally NOT container-scoped (source charges may live in satellite containers) but can only match runs the caller already owns.

[brentlogan]

@labkey-martyp, Gary installed and checked the PR and it appears to run as expected. He's going to ask Sally, our finance person, to test it. Once we get approval, we'd still like to delay the squash and merge until after our month-end billing. Monday, July 6, would be a good day. Please let us know if this causes any issues. Thanks!

[ohsudev-jonesga]

Finance team checked the outcome no issues found., There is a automated test that is failing, once cleared we will squash and merge