New value Ramp in Pathway_mode to block out transitive inconsistencies

### Describe the problem

pathways.txt` allows a set of pathways that is geometrically contradictory, and a validator currently has no reliable way to detect it. The root cause is that `pathway_mode=1` (walkway) covers both flat corridors and ramps, and `max_slope` provides no way to express "slope unknown" — it conflates *unknown* with *flat*.

This is a common configuration in large European rail stations, where entrances, concourses and platforms sit on several levels connected by a mix of stairs, ramps and lifts.

## Example

Assume one station `S` with three child locations, and that `levels.txt` is absent. (This is permitted: `levels.txt` is only *Conditionally Required* when pathways use elevators, `pathway_mode=5`, and there is no elevator here.)

**stops.txt**

| stop_id | location_type | parent_station |
|---|---|---|
| A | 2 (entrance/exit) | S |
| B | 0 (stop/platform) | S |
| C | 0 (stop/platform) | S |

**pathways.txt**

| pathway_id | from_stop_id | to_stop_id | pathway_mode | is_bidirectional
|---|---|---|---|---|
| P1 | A | B | 1 (walkway) | 1 |
| P2 | A | C | 2 (stairs) | 1 |
| P3 | B | C | 1 (walkway) | 1 |

## The problem

Take two premises a consumer would reasonably hold:

1. A walkway does not change level.
2. Stairs do change level.

Then P1 and P3 imply `level(A) = level(B) = level(C)`, while P2 implies `level(A) ≠ level(C)`. The two conclusions contradict each other, so at least one of the three pathways is mis-modelled — **or** premise 1 is false and one of P1/P3 is in fact a ramp.

To be clear about what is *not* the problem: the mere existence of a stepped route A→C alongside a step-free route A→B→C is entirely normal and expected. Stations routinely offer a short staircase and a longer accessible detour between the same pair of locations. The anomaly here is purely about the level geometry the pathway graph implies.

## Why the existing fields don't resolve it

`max_slope` looks like the field that should settle this, but its definition creates the problem rather than solving it.

The reference lists the field's valid options as "`0` or empty - No slope", followed by a float giving the slope ratio. Note what this is *not*: it is not a statement that empty defaults to zero. Empty and `0` are defined as a single option carrying a single meaning — the pathway is flat.

Furthermore, the column is optional , and can be entirely missing. In this situation, the consumer can not assume anything about whether the walkway is flat or not.

### Use cases

Automated validation of `pathways.txt`.

In my own experience, pathway data is under-published partly because producers have no way to check their own work: beyond referential integrity, there is very little a validator can currently say about whether a pathway graph is plausible. A level-consistency check would catch a class of real modelling errors — a stair pathway drawn to the wrong platform, a missing intermediate node, a ramp typed as a walkway — at feed-build time rather than in a rider's trip plan. For wheelchair users the failure mode of an undetected error is a routing result that sends them down a staircase.

Any such rule can only ever be a **warning**, since the contradiction does not identify which pathway is at fault.

### Proposed solution

**Option 1 — Add `pathway_mode=8` (ramp).**
A single unambiguous signal that a walkable pathway changes level. The backwards-compatibility problem is significant, though: ramps are legally mode 1 today, so mode 1 would remain ambiguous across every existing feed and a validator could not treat it as "flat" without a migration period and some way to tell migrated feeds from legacy ones. It also overlaps semantically with `max_slope`, which the spec has so far treated as the ramp mechanism.

**Option 2 — Recommend or require `levels.txt` alongside `pathways.txt`.**
Extend the conditional requirement from "pathways include elevators" to "pathways.txt is provided". This makes the check direct and exact, and uniquely among these options it gives the *magnitude* of the level change. Cost is real: producers must survey and assign `level_id` on every location.

### Additional information

The main goal is to enable better automatic validation of pathways.

Start with the pathways.txt and levels.txt reference requirements, then review the stops.txt and pathways.txt example in the issue. Compare the current meanings of pathway_mode and max_slope with both proposed solutions. Done requires an agreed specification change that enables level-consistency validation without leaving the intended behavior unresolved.

Written by the indexing model from the issue text.