A sealed class with no subtypes cannot be used in declarations in the same file

[Paul M. Rodriguez]

Loading this file:

```
(in-package :cl-user)

(defclass my-class ()
  ())

(declaim (sb-ext:freeze-type my-class))

;; Either one of these will trigger the bug.

;; (defun my-function ()
;; (the my-class (values (make-instance 'my-class))))

(defun my-function (x)
  (declare (my-class x))
  x)
```

Results in `Unexpected metatype for #<SB-KERNEL:WRAPPER (ID=1163) for MY-CLASS {50412B03}>`, in `sb-c::transform-instance-typep`.

This happens in SBCL 2.1.7, 2.1.9, and SBCL 2.1.9.118-d8761b1f6.

Output of `uname -a`:

```
Linux prodriguez-2102 5.4.0-89-generic #100~18.04.1-Ubuntu SMP Wed Sep 29 10:59:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
```

Value of `*features*`:

```
(:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
 :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL
 :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
 :SB-THREAD :SB-UNICODE :SBCL :UNIX)
```

[Douglas Katzman (dougk)]

Sure, it should "work" but as a practical matter sealing a standard-class achieves nothing. Its known placement in the type system will not optimize anything- not method lookup, not TYPEP.

Lest there be any doubt, search for :SEALED in the source code and you'll find that any logic surrounding the lookup of the class state applies only to structure-object and descendants.
Patches to alter that could be considered. Otherwise I'd just as soon have the compiler style-warn upon seeing the declaration, to the effect that the declaration is unsupported for the metatype. (it's nonstandard so there's no spec violation there)