Deprecate PermitException for removal in 4.0, warning only when it is read

CONTRIBUTING.md

@@ -291,7 +291,13 @@ has to be restored by hand.
 4. Do not run `ruff format` on it: `permit/api/models.py` is excluded from ruff and typos
    in `pyproject.toml` and keeps the generator's formatting, so the diff shows only API changes.
 
-5. Run the schema drift check, the offline tests under both pydantic majors (see above) and
+5. Add each new model to `__all__` in `permit/__init__.py`, and remove each deleted one:
+   `from permit import *` binds only the names `__all__` lists, and type checkers treat only
+   those as exported. `tests/test_fix_permit_exception_deprecation.py` fails until the list
+   matches. A name the models import for their own use, such as one from `typing`, goes in that
+   test's `NOT_EXPORTED` instead.
+
+6. Run the schema drift check, the offline tests under both pydantic majors (see above) and
    `uv run pre-commit run --all-files`.
 
 ### Schema drift check

MIGRATION.md

@@ -467,13 +467,17 @@ summary.
   request is sent:
 
   ```bash
-  python -m pytest -W error::DeprecationWarning -W "ignore:Use PermitError instead:DeprecationWarning"
+  python -m pytest -W error::DeprecationWarning
   ```
 
-  The second filter is needed in 2.x and 3.x alike: `import permit` warns because
-  `PermitConnectionError` subclasses the deprecated `PermitException`, and that warning comes from
-  inside the SDK. To fail on permit's flat methods only, use
-  `-W "error:permit.api.:DeprecationWarning"`.
+  It also fails on each line that imports `PermitException`, or reads `permit.PermitException`
+  or `permit.exceptions.PermitException`, as that line runs (an `except` clause reads it only
+  when an exception reaches it). A star import of `permit` or `permit.exceptions` binds
+  `PermitException`, so it fails too, even where the code never uses the name: import the names
+  the code uses instead. permit 4.0 removes `PermitException`: catch `PermitConnectionError`
+  instead. permit 2.7.0 to 3.0.0 warn on `import permit` itself ("Use PermitError instead"),
+  from inside the SDK; on those, add `-W "ignore:Use PermitError instead:DeprecationWarning"`.
+  To fail on permit's flat methods only, use `-W "error:permit.api.:DeprecationWarning"`.
 - **To silence them** while you migrate, add filters for the messages:
 
   ```ini
@@ -482,6 +486,7 @@ summary.
   filterwarnings =
       ignore:permit\.api\.\w+\(\) is deprecated:DeprecationWarning
       ignore:Support for pydantic 1:DeprecationWarning
+      ignore:PermitException is deprecated:DeprecationWarning
   ```
 
   In code: `warnings.filterwarnings("ignore", message=r"permit\.api\.\w+\(\) is deprecated", category=DeprecationWarning)`.

README.md

@@ -312,6 +312,18 @@ each one issues a `DeprecationWarning` that says what to do instead.
   query parameter the API has deprecated. Use `permit.api.resource_instances.list_detailed()`
   instead (see [Detailed lists](#detailed-lists)). Only a call that passes `detailed_key=True`
   or `detailed_key=False` warns.
+- **`PermitException`.** Catch `PermitConnectionError` instead: it is the only exception the
+  SDK raises that is a `PermitException`. permit 4.0 makes `PermitConnectionError` a direct
+  subclass of `PermitError`, so handlers of `PermitError` or `PermitConnectionError` keep
+  working. Importing `PermitException`, or reading `permit.PermitException` or
+  `permit.exceptions.PermitException`, warns at that line when it runs; later uses of an
+  imported name do not. Type checkers flag it: mypy with `--enable-error-code deprecated`,
+  pyright in strict mode. `import permit` does not issue this warning. A star import of
+  `permit` or `permit.exceptions` binds `PermitException`, so it warns once, at the star-import
+  line, even where the code never uses the name; importing the names the code uses avoids it.
+  Until you change the code, the warning filter
+  `ignore:PermitException is deprecated:DeprecationWarning` silences it. Filters for the
+  message of earlier releases, "Use PermitError instead", do not match it.
 
 By default, Python shows these warnings only when the code that triggers them is in
 `__main__`, such as the script you run. pytest shows them in its warnings summary. To see