Preserve interception markers in parameter types (#85526)
### What?
This PR preserves the specific interception route markers in dynamic
parameter types throughout the routing system.
### Why?
Previously, the code only tracked whether a parameter was intercepted
(using generic types like `'dynamic-intercepted'` or
`'catchall-intercepted'`) but not which specific interception marker was
used. This meant that routing information about the interception pattern
was being lost.
Interception routes use different markers:
- `(.)` - matches segments at the same level
- `(..)` - matches segments one level up
- `(..)(..)` - matches segments two levels up
- `(...)` - matches segments from the root app directory
Without preserving the specific marker, the routing system couldn't
properly distinguish between these different interception patterns,
which could lead to incorrect route matching behavior.
### How?
The fix encodes the specific interception marker pattern directly in the
type definition. For example:
- `'dynamic-intercepted'` → `'dynamic-intercepted-(.)'`,
`'dynamic-intercepted-(..)'`, etc.
- `'catchall-intercepted'` → `'catchall-intercepted-(.)'`,
`'catchall-intercepted-(..)'`, etc.
This change is propagated throughout the routing system:
- Type definitions in `app-router-types.ts` and `types.ts`
- Route parameter parsing in `route-params.ts`
- Static path generation in `build/static-paths/app.ts`
- Dynamic parameter utilities in `get-dynamic-param.ts` and
`get-segment-param.tsx`
- On-demand entry handling in development mode
NAR-486