[Enhancement]: Add `logical_case_id` for higher-level case continuity (follow up to #193)

## Is your feature request related to a problem?

Issue #193 proposes normalizing `Case` identity on `(case_name, machine_id, hpc_username)` to avoid false merges between unrelated same-name cases.

That addresses ingestion identity, but it does not fully solve logical continuity. The same scientific/logical case may still span:

1. user hand-offs
2. machine moves
3. other provenance changes that should not necessarily create a brand new higher-level case concept

Without a higher-level logical identifier, the normalized model may correctly split provenance-level case rows while still lacking a durable way to regroup them when they are actually the same logical case.

A related motivation is linking external artifacts such as zppy diagnostics to a stable higher-level case identity when continuity across user or machine changes matters.

## Describe the solution you'd like

Add a higher-level `logical_case_id` concept on top of normalized `Case` rows.

Recommended model:

- `(case_name, machine_id, hpc_username)` = concrete ingested case identity
- `logical_case_id` = higher-level grouping for the same logical/scientific case across users or machines

Potential implementation directions:

1. add nullable `logical_case_id` to `cases`
2. or add a dedicated `logical_cases` table and reference it from `cases`

Expected capabilities:

- preserve strong default separation introduced by #193
- allow intentionally related case rows to be grouped together
- provide a safer long-lived identifier for cross-artifact linking (for example, zppy diagnostics)
- support future workflows such as manual/admin case joins

## Describe alternatives you've considered

### 1. Stop at #193 only
- Simpler
- Prevents false merges
- Still leaves no higher-level identity for true hand-offs or machine moves

### 2. Keep grouping only by `case_name`
- Preserves continuity
- Reintroduces false merges and weakens external artifact linking

### 3. Use `case_hash` as the higher-level identifier
- Not recommended
- `case_hash` is not stable enough to represent a persistent logical case across executions

## Additional context

This issue should be treated as follow-up work to #193, not part of the initial normalization change.

Suggested sequencing:

1. complete #193 to normalize ingestion identity
2. evaluate whether `logical_case_id` should be seeded automatically during migration or introduced in a later schema/API step
3. add API and UI support for viewing/grouping normalized case rows by logical case

Open questions:

1. Should `logical_case_id` be a column on `cases` or a dedicated `logical_cases` table?
2. Should migration seed one shared `logical_case_id` for case rows split from a pre-#193 merged case?
3. Should zppy diagnostics attach to normalized `Case` rows, `logical_case_id`, or both?