remote_operations.ts is generated unscoped, so it tracks whoever ran CodeGen last

## Problem

`packages/MJCoreEntities/src/generated/remote_operations.ts` is a **core** artifact, but the generator emits whatever `MJ: Remote Operations` rows the connected database holds, with no schema or app scoping.

[`remote_operations_codegen.ts:41-44`](https://github.com/MemberJunction/MJ/blob/next/packages/CodeGenLib/src/Misc/remote_operations_codegen.ts#L41-L44):

```ts
const active = remoteOps
.filter((o) => o.Status === 'Active')
.sort((a, b) => a.OperationKey.localeCompare(b.OperationKey));
```

`Status === 'Active'` is the only filter.

## Consequence

The committed file currently carries **42** exported operation classes. A clean database built from this repo's migrations + metadata produces **31**. The extra 11 are all `Orders*`:

```
OrdersAdvanceOrderStateOperation OrdersApplyAccountCreditOperation
OrdersCancelSubscriptionOperation OrdersCapturePaymentOperation
OrdersFulfillOrderLinesOperation OrdersGetFulfillmentQueueOperation
OrdersGetOverdueWorklistOperation OrdersPreviewPriceOperation
OrdersPriceOrderOperation OrdersRefundPaymentOperation
OrdersSpawnRenewalsOperation
```

They come from a developer's local `bizapps_orders` install, not from anything this repo ships.

So the file oscillates:
- regenerate on a **core-only** database → 31 classes, the 11 are **deleted** (observed: 1,173-line deletion)
- regenerate with **Orders installed** → they come back

Whichever way it lands, developers on the other side get a large diff they didn't cause, and real drift becomes indistinguishable from noise.

## Why this is worth fixing rather than tolerating

- A **release-time regeneration on a clean database would silently delete 11 published classes.**
- `check:codegen-tail` does not cover this file — it guards the three *entity* artifacts (`entity_subclasses.ts`, resolvers, forms), and its own header documents that scope.
- It has already flipped once. Whoever committed the 42 didn't intend to publish app-specific operations into core.

## Suggested direction

Scope the generator rather than trying to "clean up" by regenerating:

1. Filter core generation to core operations (by schema / owning app), **or**
2. Emit app operations into the owning app's package, leaving `MJCoreEntities` core-only.

Either makes the artifact a function of the repo instead of a function of whose laptop ran CodeGen.

## How it surfaced

Found while verifying PR #3980 on a clean-room database. The regenerated file was **excluded** from that PR and restored to its committed state, precisely to avoid shipping the deletion.

Start with packages/CodeGenLib/src/Misc/remote_operations_codegen.ts at lines 41-44 and inspect how remote operations identify their schema or owning app. Regenerate packages/MJCoreEntities/src/generated/remote_operations.ts against the clean-room database and verify that core generation is deterministic, excludes Orders operations, and preserves the expected core operation classes.

Written by the indexing model from the issue text.