refactor(create-model): simplify create model UI to a single name input, use Edvise Design System for input errors

[mrmaloof]

Description

Simplifies the Create Model admin page to a single model name field and aligns form styling and validation errors with the Edvise Design System.

UI (CreateModel.jsx)

• Removes batch schema config checkboxes (PDP / Custom) and the “model is valid” radio group
• Submits only { name } to POST /create-model
• Applies design-system input styles (rounded inputs, label typography) and error state (input.error, text-danger)
• Improves accessibility (aria-invalid, aria-describedby, role="alert")

Backend proxy (ApiController::createModelApi)

• Stops forwarding optional vers_id, valid, and schema_configs to the API
• Removes the local-only mock success response so local env hits the real API path

Styles

• app.css: label defaults; input.error uses border-danger on hover/focus
• tailwind.config.js: danger color tokens

Companion change: Pairs with the edvise-api PR that simplifies POST /institutions/{inst_id}/models/ to accept name only and default valid=true on create.

Deployment Readiness*

Testing

Describe or check:

• Created or updated unit, feature, and/or integration tests
• Typical manual testing in the local env browser, dev pipeline, etc.

Notes: No automated tests cover this page today. Manually verified as a DATAKINDER user:

• Empty submit → browser validation message under the field
• Invalid characters → pattern validation message
• Valid name → success (“Done”)
• API error (e.g. duplicate name) → error shown under input via text-danger
• Reset clears field and errors

Deployment Notes

Describe or check:

• No special deployment steps required

Deploy with the matching edvise-api change so create-model does not send removed fields. No migrations or env var changes.

Rollback Plan

Describe or check:

• Standard revert is sufficient (git revert)

Reviewer Guidance / Questions*

• Confirm with product that schema config and “valid” toggles are no longer needed on create (models are created name-only; API sets valid=true).
• Should result_area success/error copy be refined in a follow-up (still uses simple “Done” / JSON for some errors)?

Screenshots / Testing Evidence*

SOC 2 Change Management Checklist

• None of the below are true in this code
• New roles/permissions are introduced without review and approval by the product manager
• Hardcoded credentials, secrets, or API keys are present in this code
• Secrets are being managed outside of the approved secrets management process (e.g., GitHub Secrets, environment variables)
• PII or sensitive data handling is introduced or changed without being reviewed against our data classification policy
• Sensitive data is written to logs
• Input validation and sanitization is missing
• An unnecessary attack surface has been introduced (e.g., unused endpoints, open ports, debug modes left enabled)
• Common vulnerabilities have been introduced in the code (inc. any dependencies added or updated)
• No review for common vulnerabilities has been conducted
• Not tested in a non-production environment
• Breaking changes to existing APIs or integrations with downstream consumers being notified
• Performance impact has not been considered or acceptable
• Appropriate audit logging is missing for any security-relevant actions introduced by this change
• Log entries contain sensitive or PII data
• All existing tests do not pass locally (./vendor/bin/pest)

---

Reminder for Reviewers: By approving this PR you are confirming that you have reviewed the code for correctness, security, and compliance with our engineering and SOC 2 standards. Do not approve PRs where SOC 2 checklist items are checked without documented justification.

*Optional