fix: address vale linting issues

- Change heading to sentence-style capitalization
- Remove unnecessary adverb 'properly'
- Use contraction 'isn't' instead of 'is not'
- Add 'HTTP' prefix to PATCH to clarify acronym

Co-Authored-By: Devin Logan <[email protected]>

Author: devin-ai-integration[bot]

fern/products/api-def/ferndef-pages/types.mdx

@@ -27,11 +27,11 @@ Types describe the data model of your API.
 | `file` | File upload type, e.g., [file uploads](/learn/api-definition/fern/endpoints/multipart) |
 | `unknown` | Represents arbitrary JSON |
 
-### Optional vs Nullable
+### Optional vs nullable
 
-Understanding the difference between `optional` and `nullable` is important for properly modeling your API:
+Understanding the difference between `optional` and `nullable` is important for modeling your API:
 
-- **`optional<T>`**: The field can be omitted from the request/response entirely. When omitted, the field is not sent over the wire.
+- **`optional<T>`**: The field can be omitted from the request/response entirely. When omitted, the field isn't sent over the wire.
 - **`nullable<T>`**: The field must be present but can be explicitly set to `null`. This allows you to distinguish between "not specified" and "explicitly cleared".
 
 ```yaml
@@ -43,12 +43,12 @@ types:
       bio: nullable<string>       # Must be present, but can be null
 ```
 
-This distinction is particularly important for PATCH requests where you need to differentiate between:
+This distinction is particularly important for HTTP PATCH requests where you need to differentiate between:
 1. **Omitting a field** - Don't update this field (keep existing value)
 2. **Setting to `null`** - Clear this field (remove the value)
 3. **Setting to a value** - Update this field with a new value
 
-#### Example: PATCH request semantics
+#### Example: HTTP PATCH request semantics
 
 ```yaml
 types: