No top-level interface to the engine's tower rings

This issue was triaged from [`bugs/dan/0-engine-tower-rings`](https://github.com/Macaulay2/M2/blob/388c1ff0ce30d83751dea7bc7eac77fdc1305dd7/bugs/dan/0-engine-tower-rings), one of the 857 files removed from the pre-GitHub `bugs/` tree by [`d2c8d27826`](https://github.com/Macaulay2/M2/commit/d2c8d27826) and catalogued in [#36](https://github.com/Macaulay2/M2/issues/36). **The commentary below was written by Claude (Claude Opus 5, via Claude Code)**, not by @d-torrance, whose account posted it -- please weigh it accordingly.

### The original file, verbatim

```text
A = engineTowerRing N
A = engineTowerRing (N,{z,a,b,c})
R = A / (f(a,b,c), g(b,c), h(c)) -- we pass 0 as the relation for z
R = A / ideal (f(a,b,c), g(b,c), h(c))
R = A / {f(a,b,c), g(b,c), h(c)}
class EngineTowerRing
promote and lift should work
```

### Where it stands today

The raw hooks exist and are complete; what is missing is any front end. And there are **two**
implementations, which is the first thing to settle.

### What exists

| | file | lines | base ring | reachable how |
| --- | --- | ---: | --- | --- |
| `Tower` | `e/rings/tower.cpp` | 560 | `ZZ/p` | `rawTowerRing*`, and the monoid option `Constants => true` |
| `ARingTower` | `e/basic-rings/aring-tower.{cpp,hpp}` | 438 + 614 | **`ARingZZpFFPACK` only** | `rawARingTower*` — no callers anywhere |

Both wrap the same arithmetic core, `DPoly`/`DRing` in `e/rings/dpoly.hpp`, and all six raw entry
points are wired into `d/interface.dd`. None is exported, so from a user session `rawTowerRing(...)`
is a `Symbol` until you `debug Core`. Both print as `Tower[ZZ/5[x,y,z]]`, so they are
indistinguishable from above.

Note that `ZZ[x][y][z,w]` does **not** reach either: the engine sees one flat `PolyRing` over `ZZ`
with four variables, and the tower is front-end bookkeeping.

### What the towers are for, and the one thing they do better

From the top of `dpoly.hpp`: *"Code for univariate polynomials over algebraic extensions of QQ and
over finite fields … monic gcd mod p over extension fields, modular gcd algorithm."* And that shows
up measurably. For two polynomials sharing the factor `x^5 + a*x + b` over `F5[a]/(a²-2)[b]/(b²-a)`:

| | result |
| --- | --- |
| `Tower`, via `rawTowerQuotientRing` | `x5+ax+b` — **correct** |
| flat ring + factory | **`1` — wrong** (and `f % d == 0`, `g % d == 0` both hold) |

That wrong answer is #4583. The tower representation is immune to it because the extension chain is
part of the ring rather than something factory must be told.

### What is broken on the only reachable route

`(ZZ/5)[x,y,z, Constants => true]` (`polyrings.m2:163-164`, carrying `-- TODO: document this`) gives
a `PolynomialRing` over a tower with **no relations**, where those univariate algorithms do not apply
and fail silently: `rawGCD(raw x, raw x)` is `0`, `x^2 % x` is `x^2`, `x^2 // x` is `0`,
`promote(1_(ZZ/5), R)` errors, and `gens gb ideal(x^2-y)` **segfaults** in
`GaussElimComputation::insert` (`e/gauss.cpp:50`). Test coverage is two tests in
`unit-tests/RingTowerTest.cpp`.

### What Dan asked for

`engineTowerRing`, a `class EngineTowerRing`, quotients by a tower of relations, and working
`promote`/`lift` — of which `promote` is precisely what fails first today.

_{`open` · disposition `issue` · source of truth: [`bug-triage/catalog.tsv`](https://github.com/d-torrance/M2/blob/bug-triage/bug-triage/catalog.tsv)}

Start by reading e/rings/tower.cpp, e/basic-rings/aring-tower.cpp and .hpp, d/interface.dd, and unit-tests/RingTowerTest.cpp to compare the two existing implementations and their raw entry points. Done means choosing and exposing a top-level engineTowerRing interface with tower relations, working promote/lift behavior, and coverage for the intended quotient operations.

Written by the indexing model from the issue text.