Added a convention that sentinel errors go near the top of the file, and applied it

CODE_CONVENTIONS.md

@@ -589,10 +589,36 @@ Two kinds of error are exempt and have no prefix:
   an internal package name.
 - Error text that is part of a protocol sent to a client, such as the
   mock Find a Tender API's error responses, which match the real API's.
-- Errors that callers test for are sentinel values named `Err…`
-  (exported) or `err…` (unexported), checked with `errors.Is`. A
-  package's sentinels go in one commented `var` block (see
-  [Grouped declarations](#grouped-declarations)).
+
+### Sentinel errors
+
+Errors that callers test for are sentinel values named `Err…` (exported)
+or `err…` (unexported), checked with `errors.Is`. The sentinels in a file
+go in one commented `var` block (see
+[Grouped declarations](#grouped-declarations)).
+
+They are declared near the top of the file: straight after the imports
+and any constants, before the file's types and functions. A reader then
+sees what the file can fail with before reading how, and finds a
+sentinel without searching the file. This applies to every package-level
+error variable, in tests as well.
+
+```go
+import (
+	"errors"
+	"time"
+)
+
+// ErrWonAndLost is returned by OpportunityMarks.Validate when both Won and
+// Lost are set.
+var ErrWonAndLost = errors.New("types: an opportunity cannot be both won and lost")
+
+// Opportunity is a procurement opportunity ...
+type Opportunity struct {
+```
+
+Not declared next to the type or function that returns it, partway down
+the file.
 
 ### Ignoring an error