Add telemetry error classification guardrails

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,7 +4,17 @@
 ## Testing
 <!-- Describe how the changes have been tested-->
 
+## Telemetry Errors
+<!--
+If this PR adds or changes an error emitted by the JDBC driver, complete both
+"Applicable" items. Otherwise check "Not applicable" only.
+-->
+- [ ] Not applicable — this PR does not add or change a telemetry-visible error.
+- [ ] Applicable — the error uses `DatabricksDriverErrorCode` where appropriate, and any
+      new code is uniquely numbered and tested.
+- [ ] Applicable — its driver/server/user classification is linked, or maintainer help is
+      requested because the author cannot access the classification.
+
 ## Additional Notes to the Reviewer
 <!-- Share any additional context or insights that may help the reviewer understand the changes better. This could include challenges faced, limitations, or compromises made during the development process.
 Also, mention any areas of the code that you would like the reviewer to focus on specifically. -->
-

CLAUDE.md

@@ -14,6 +14,19 @@
 - `src/test/java/com/databricks/jdbc/` — unit and integration tests
 - `development/.release-freeze.json` — controls release freeze state
 
+## Telemetry Error Changes
+
+When adding or changing an error emitted by the JDBC driver:
+
+- Use `DatabricksDriverErrorCode` wherever a driver-owned error code applies. Reuse an
+  existing code when its meaning matches; otherwise add a uniquely numbered enum value.
+- Add or update a test that verifies the emitted error name and numeric code.
+- Record whether the error is a driver, server, or user error in the maintainers' OSS JDBC
+  telemetry dashboard and automation taxonomy. Link that update in the PR, or explicitly
+  ask a maintainer to make it if you do not have access. Do not infer the classification
+  from the error name alone.
+- Complete the telemetry-error section of the pull-request template.
+
 ## PR Checks — Common Pitfalls
 
 ### 1. DCO Sign-off (required)