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

[tomvothecoder]

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 [Enhancement]: Normalize Case identity to (case_name, machine, hpc_username) #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 [Enhancement]: Normalize Case identity to (case_name, machine, hpc_username) #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-[Enhancement]: Normalize Case identity to (case_name, machine, hpc_username) #193 merged case?
3. Should zppy diagnostics attach to normalized Case rows, logical_case_id, or both?

[tomvothecoder]

@rljacob What do you think about this solution for case continuity? It adds a higher-level grouping identifier called logical_case_id which can be set manually by admins/owners to group same cases ran by different users or on different machines.

This works together with the case_name, machine, hpc_username identifier in #193.