Support row-level dynamic cell typing

## Problem

Some artifacts output heterogeneous values within a single column (e.g. name/value datasets where one row contains a timestamp, another a username, another a phone number). Today, data typing is declared at the column level only, which prevents correct rendering in LAVA when values vary by row.

We want to support row-level cell typing without:
- Inline/in-content tagging
- Scanning all values heuristically
- Adding table/row abstraction layers
- Forcing module developers to manage extra columns or row identifiers

## Constraints / Design Principles

- Artifacts currently declare schema via a header row, using native Python structures
- Rows are returned as plain lists/tuples (no row objects)
- Artifacts should not return tuples as values unless explicitly declaring a data type
- The framework should assemble any additional metadata needed for LAVA

## Proposed Approach

Allow artifacts to declare row-level typing by returning typed cell tuples in row data.

### Typed cell format

A cell value may be returned as: `(value, lava_type)`

Examples:
``` python
("2026-01-13T10:05:00Z", "datetime")
("+1-555-555-5555", "phonenumber")
```

Rules:

- Tuples returned by artifacts are reserved exclusively for typed cells
- Any tuple in row data is treated as (value, lava_type)
- Any tuple with unknown data type treated as raw
- All non-tuple values are treated as raw

### Framework responsibility

During output generation:

- Strip typed tuples down to their raw value for output
- Assemble a reserved per-row JSON column mapping column name → lava_type
- Exclude the reserved column from HTML output

Example output with multiple column types:
```
{
"prop_value_1": "phonenumber",
"prop_value_2": "datetime"
}
```

### Reserved column name options

One column per table, generated by the framework. Name options:

1. __lava_types
2. __lava_cell_types
3. _lava_column_types

Open Questions:
1. Hidden column name (see above)?
2. Do we want to have an artifact level config value to serve as an enable switch to prevent accidental data renders?
3. Do we want to have an artifact table header level declaration (such as `polytyped`) to enable that column for row level typing?

summary assisted by ai after discussion with @prosch88