Add larger MEDS-Tab variants alongside meds_tab/tiny

The only MEDS-Tab variant currently registered is meds_tab/tiny — explicitly described as "a tiny, low-cost XGBoost baseline." Add at least one (ideally two) larger variants so MEDS-Tab can be evaluated as a competitive baseline rather than just a smoke-test.

What this needs

New sibling dirs under src/MEDS_DEV/models/meds_tab/, e.g.:

• meds_tab/standard/ — moderate-capacity sweep (more codes, more window sizes, more trials).
• meds_tab/large/ — wider sweep / more aggregation types, intended as the "best-effort" tabular baseline.

Naming is up to @Oufattole / @teyaberg — the point is capacity variants, not new framework features.

Knobs to scale up

Pulling from meds_tab/tiny/model.yaml, the obvious dimensions are:

• tabularization.aggs — currently [code/count, value/sum]. Add value/min, value/max, value/mean, value/std, etc.
• tabularization.window_sizes — currently [7d, 30d]. Add shorter (1h, 6h, 24h) and longer (90d, 365d) windows.
• tabularization.max_included_codes — currently 100. Bump to 1000 / 10000 / unbounded.
• tabularization.min_code_inclusion_count — currently null. Could constrain for the larger sweep.
• hydra.sweeper.n_trials — currently 20. Bump for the larger variants.
• hydra.sweeper.n_jobs — currently 1. Parallelize where appropriate.

Open questions

• Capacity nomenclature: tiny/small/base/large vs tiny/standard/large vs something else?
• Where does the gradient from "tiny" to "large" sit on real benchmark wall-clock — worth pinning at least one variant's hyperparams to what was used in the MEDS-Tab paper?

Pinging @Oufattole, @teyaberg — best to take the lead on what hyperparams make sense.

Refs

• Paper: https://arxiv.org/abs/2411.00200
• Existing variant: meds_tab/tiny/model.yaml

Start with src/MEDS_DEV/models/meds_tab/tiny/model.yaml and inspect how sibling model directories are registered. Compare the tiny settings with the MEDS-Tab paper and resolve the capacity naming and hyperparameters with the mentioned maintainers. Done means at least one larger sibling variant is configured and available for benchmark evaluation.