Add structured test and environment attributes for result analysis

## Context

Some information needed to understand test failures is currently encoded in test names or configuration names.

Filesystem testing provides a useful example. A test such as generic/234 may run against ext4, XFS, btrfs, or f2fs; 1k or 4k block sizes; DAX configurations; and filesystem-specific configurations.

Similar correlations can exist with environment characteristics such as architecture, memory availability, storage type, or other hardware properties. Encoding these dimensions only in test names makes it difficult to aggregate, filter, and correlate results.

## Goal

Investigate a structured model for representing relevant test configuration and execution-environment attributes.

This should enable the dashboard and reporting tools to answer questions such as:
• Does this failure affect only one architecture?
• Is it specific to a filesystem?
• Does it correlate with block size?
• Does it happen only on SSDs or HDDs?
• Does it correlate with memory constraints?

Points to discuss
• Which attributes belong to the test, test configuration, environment, or hardware.
• Which attributes KernelCI already receives from labs.
• Whether test suites need to provide suite-specific dimensions.
• How attributes should be submitted and stored.
• How to avoid making the model specific to filesystem testing.
• How these attributes can power filtering, aggregation, and reporting.

No files, tests, or entry points are identified in the issue. Start by tracing how the dashboard and reporting tools receive and store test results and lab environment data, then document a technology-neutral attribute model and submission path that supports filtering, aggregation, and correlation across test configurations and hardware.

Written by the indexing model from the issue text.