[TASK] Apply code style for "enum" like string constants

### Description

Implement the agreed approach to "enum" like string constants. Benefits:

- Self-explanatory business rules: The code reads clearly. For example `InstancePayloadStatus.READY` instantly tells you what it’s about.
- Distinct grouping: It’s obvious that `InstancePayloadStatus.READY` is separate from `TransactionStatus.READY` (just example names), avoiding confusion between similar values.
- Fewer mistakes: It reduces typos and enforces a clear scope for these strings, making the code more reliable.

---

### Checklist
- [x] **Does it need UI/UX design?**
- No
- [x] **Does it need API design?**
- No
- [x] **Does it need design around state flow?**
- No
- [x] **Does it need a test plan?**
- No

---

### Design

- Do a full pass in the project to ensure consistency across
- Continue to use the type EnumerationName = UNION | OF | STRING | LITERALS, but use a shared prefix for each member of the union
- Use CAPS_SNAKE_CASE across the board
- Hopefully, with a lint rule in tow so, it's more than a convention-by-handshake
- Add documentation about this approach in a code style section

---

### Dependencies
To do after the editing work is merged

- https://github.com/getodk/web-forms/pull/334
- https://github.com/getodk/web-forms/pull/335
- https://github.com/getodk/web-forms/pull/336
- + the other upcoming 1 or 2 PRs related to edit

---

### Related Issues

- [Slack](https://getodk.slack.com/archives/C051L6AKG4F/p1741888706927129)

No files, tests, or entry points are named; begin with a repository-wide review of TypeScript string-union constants and the existing lint configuration. The work is done when enum-like constants consistently use shared CAPS_SNAKE_CASE prefixes, lint enforcement is added if appropriate, and the code-style documentation describes the convention.

Written by the indexing model from the issue text.