Add meds-dev-submit-result CLI: client-side submission via gh

Follow-up to PR #295's design discussion (thread).

Today the result-submission flow is: a contributor runs meds-dev-pack-result to produce result.json, then manually navigates to the GitHub issue form, pastes the JSON into a fenced code block, types the dataset / task / model names by hand, and submits. The submission workflow then parses that issue body and validates.

There are a few sharp edges here:

1. Free-text typing of dataset/task/model invites mistakes (handled separately in #296).
2. Manual copy-paste between a JSON file and a textarea invites copy errors.
3. The contributor doesn't see whether the JSON is valid until after the workflow has fired (or until they trigger validation locally with meds-dev-validate-result, which is a separate step).
4. Submission requires browser navigation, which interrupts a CLI-driven workflow.

Proposal: meds-dev-submit-result <result.json>

A client-side CLI that does the whole thing in one step:

meds-dev-submit-result path/to/result.json

What it does:

1. Loads and validates the JSON locally via Result.from_json (the existing logic). Fails fast with a clear error if invalid — contributor never gets a "broken submission" issue filed.
2. Confirms the GitHub repo (Medical-Event-Data-Standard/MEDS-DEV by default; configurable for forks/testing).
3. Builds the issue body with the JSON pre-pasted into the right shape, the typed fields pre-filled from the parsed JSON (result.dataset → form field, etc.), and the result-submission label applied.
4. Opens the issue via gh issue create (relies on the local gh auth).
5. Returns the issue URL.

Implementation lives in MEDS_DEV.web.submit_result (or submit_submission); CLI: meds-dev-submit-result.

Why this is better than form-only

• Validation happens client-side, so invalid submissions never reach the workflow at all.
• No copy-paste: the JSON is read from disk; the form fields are derived from it.
• No browser: contributors in a CLI loop can submit without context-switching.
• Form fields and JSON are guaranteed to match because both are populated from the same parsed Result object.
• Plays well with the existing form: web-form submissions still work for users who don't want to install meds-dev. The CLI is opt-in convenience, not a replacement.

Open questions

• Should the CLI also poll for issue closure and report success/failure back to the user?
• What about non-Medical-Event-Data-Standard forks? Default to whatever gh repo view returns? Take an explicit --repo flag?
• For users who already use gh issue create directly: should there be a --print-body mode that just emits the body for piping (meds-dev-submit-result --print-body x.json | gh issue create --body-file -)?
• Could this CLI eventually open a PR against the _results branch directly, bypassing the issue layer entirely? (Speculative; would need different permission model.)

Acceptance criteria

• meds-dev-submit-result <result.json> validates and submits in one invocation.
• Local validation: invalid JSON, missing fields, NaN values, etc. are caught before the issue is opened.
• Authenticated via the user's gh CLI; no token-management required.
• Doctest / unit-test coverage for the body-building logic (no live GitHub call required for those).
• Mention in src/MEDS_DEV/web/README.md as the recommended submission path; preserve the form as a fallback.

Related

• PR #295 — surfaced this as a follow-up.
• #296 (stricter form) — orthogonal improvement to the form-based submission path. Both can land; they don't conflict.

Start with MEDS_DEV.web.submit_result or submit_submission and the existing Result.from_json validation flow, then trace how the current result-submission issue body is formed. Add unit or doctest coverage for body building without a live GitHub call, and update src/MEDS_DEV/web/README.md. Done means the CLI validates a result.json, uses authenticated gh to create the issue, and returns its URL.