Typed/untyped interop is unsound for structs, given a sufficiently powerful inspector

As reported by @LiberalArtist on the mailing list, a sufficiently powerful inspector can break type system invariants and create unsoundness due to insufficient protection of reflective operations on structs. Here’s a self-contained program that reproduces the issue and demonstrates the unsoundness:

#lang racket

(module s typed/racket
  (provide (struct-out must-be-integer)
           must-be-integer-add1)
  (struct must-be-integer ([v : Integer]))
  (define (must-be-integer-add1 [x : must-be-integer])
    (add1 (must-be-integer-v x))))

(require racket/runtime-path)

(define-runtime-module-path-index s-mpi '(submod "." s))

(define-values [must-be-integer must-be-integer-add1]
  (parameterize ([current-inspector (make-inspector)])
    (values (dynamic-require s-mpi 'must-be-integer)
            (dynamic-require s-mpi 'must-be-integer-add1))))

; Succeeds, but shouldn’t!
(define-values [struct:must-be-integer* skipped?] (struct-info (must-be-integer 1)))
((struct-type-make-constructor struct:must-be-integer*) "not an integer")

; Also succeeds, but shouldn’t!
(must-be-integer-add1 ((struct-type-make-constructor struct:must-be-integer*) "not an integer"))

This is possibly caused by racket/racket#2359.

Run the self-contained program in the issue to reproduce both unsound behaviors, then read the reflective struct operations it exercises and racket/racket#2359. Determine the required protection for typed/untyped struct interop and add regression coverage showing that neither operation can violate the integer invariant under a sufficiently powerful inspector.