GetDescendants/GetAncestors return [] silently when the entity's view lacks hierarchy columns

## Problem

`BaseEntity.GetDescendants()` / `GetAncestors()` resolve a recursive FK through a three-step fallback in [`baseEntity.ts:4990-5002`](https://github.com/MemberJunction/MJ/blob/next/packages/MJCore/src/generic/baseEntity.ts#L4990-L5002):

1. a field with `IsHierarchy = true`
2. **a field named `parentid`**
3. **any recursive FK**

Steps 2 and 3 do **not** check whether the entity's base view actually projects the hierarchy columns. The methods then build a `RunView` filter on `Root` and `Depth`:

```ts
const filter = maxDepth != null
? `${rootFieldName} = '${rootId}' AND ${depthFieldName} <= ${maxDepth}`
: `${rootFieldName} = '${rootId}'`;
```

If those columns don't exist, `RunView` fails and the method returns `[]`:

```ts
return result.Success ? (result.Results ?? []) : [];
```

**A failed query is indistinguishable from "no descendants."** Nothing is logged.

## Who this affects

Any entity with a self-referencing FK whose base view is not generated (`BaseViewGenerated = 0`) — CodeGen has nowhere to project hierarchy columns and skips it **silently**, with no warning in the CodeGen log either.

There are **19** such entities today. Two have self-referencing FKs and are therefore live instances of this bug:

| entity | field | reached by |
|---|---|---|
| `MJ: Entities` | `ParentID` | fallback step 2 (field named `parentid`) |
| `MJ: Employees` | `SupervisorID` | fallback step 3 (any recursive FK) |

`MJ: Entities` is the metadata table itself, so this is reachable from any entity tree view.

## Note

PR #3980 removes the `IsHierarchy=true` seed entries for both, which stops metadata *advertising* traversal that cannot work. It does **not** fix this — steps 2 and 3 still match, so the silent `[]` remains. That PR's description says so explicitly.

## Suggested direction

Either:

1. **Gate the fallback** — require that the resolved field's entity actually exposes `Root` / `Depth` before returning it, or
2. **Surface the failure** — `LogError` and/or propagate when `result.Success` is false, so a broken query stops looking like an empty result.

(2) is worth doing regardless of (1): silently swallowing a `RunView` failure is what made this invisible.

## How it surfaced

Found while scoping PR #3980, in an adversarial review of why two seeded hierarchy fields produced no columns.

Read packages/MJCore/src/generic/baseEntity.ts at lines 4990-5002 and trace the GetDescendants/GetAncestors fallback resolution and RunView result handling. Determine whether to gate fallback fields, surface failed queries, or both. Done means missing hierarchy columns no longer produce an indistinguishable empty result, with behavior covered by an appropriate test.

Written by the indexing model from the issue text.