Now I've always thought that "encapsulation" is almost synonymous with encryption.
You protect a **pre-established** value using a mechanism.

This is not how the term has ever been used in the literature.

The definition of public-key key encapsulation has been consistent since Shoup introduced it in 2000 (emphasis added):

We describe here a general method for constructing a hybrid encryption scheme.
To this end, it is convenient to define the notion of a *key encapsulation scheme*.
This is a scheme that allows a party to generate a random bit string and send it to another party, encrypted under the receiving party’s public key.

**A key encapsulation scheme works just like a public key encryption scheme, except that the encryption algorithm takes no input other than the recipient’s public key.**
Instead, the encryption algorithm generates a pair $(K, \psi)$, where $K$ is a random bit string of some specified length, say $l$, and $\psi$ is an encryption of $K$, that is, the decryption algorithm applied to $\psi$ yields $K$.

One can always use a public key encryption scheme for this purpose, generating a random bit string, and then encrypting it under the recipient’s public key.
However, as we shall see, one can construct a key encapsulation scheme in other ways as well.

—Victor Shoup, “Using Hash Functions as a Hedge against Chosen Ciphertext Attack”, in Bart Preneel (ed.), *Advances in Cryptology—EUROCRYPT 2000*, Springer, Lecture Notes in Computer Science, vol. 1807, ISBN 978-3-540-67517-4, ISSN 0302-9743, § 4.2 “A General Hybrid Construction”

This definition has been maintained consistently in the literature in the decades since then.
See, for example:

*Abstract* … A KEM is a probabilistic algorithm that produces a random symmetric key and an asymmetric encryption of that key. …

…

A KEM is a triple of algorithms: …

- a encapsulation algorithm, $\mathit{KEM.Encap}$, that takes as input a public-key $\mathit{pk}$ and outputs an encapsulated key-pair $(K, C)$ ($C$ is sometimes said to be an encapsulation of the key $K$),

—Alexander W. Dent, “A Designer's Guide to KEMs”, Cryptology ePrint Archive, Paper 2002/174, 2002.

3.26 **key encapsulation mechanism**: similar to an asymmetric cipher, but the encryption algorithm takes as input a public key and generates a secret key and an encryption of this secret key. *(See Clause 8.1.)*

…

8.1 Key encapsulation mechanisms

A key encapsulation mechanism KEM consists of three algorithms: …

- An encryption algorithm $\operatorname{\mathit{KEM.Encrypt}}(\mathit{PK}, \mathit{opt})$ that takes as input a public key $\mathit{PK}$, along
with an encryption option $\mathit{opt}$, and outputs a secret-key/ciphertext pair $(K, C_0)$.
Both $K$ and $C_0$ are octet strings.

—Draft ISO/IEC 18033-2: Information technology—Security techniques—Encryption algorithms—Part 2: Asymmetric Ciphers, Victor Shoup (ed.), 2004.
(Final version hidden behind ISO paywalls.)

This draft goes on to detail ECIES in particular as a key encapsulation mechanism in § 10.2—combined with a data encapsulation mechanism to make an encryption scheme.

Your factoring of ECIES is a legitimate view:

ECIES consists of the following:

- key agreement using ECDH, giving the master secret;
- key derivation using a KBKDF which results in the symmetric data key being established;
- some kind of data encapsulation using the derived symmetric data key.

But you can also view steps (1) and (2) as a function only of the public key—the message to be encrypted is not involved yet, not until step (3)—that turns out to be a key encapsulation method.
Combining the KEM of steps (1) and (2) with the DEM of step (3) gives public-key encryption.

(Note: Key *agreement*, or key *exchange*, as in Diffie–Hellman, always has two parties contributing non-secret inputs to agree on a secret output.
As you see, you can derive key *encapsulation* from key *agreement* by using one of the non-secret inputs as a public key, generating the other non-secret input independently for each message, and sending the per-message non-secret input as a key encapsulation alongside the ciphertext.
Whether it's secure depends on the details, but it always syntactically works out.)

The term has plenty of more recent examples—it is now the dominant paradigm for designing public-key encryption schemes today, including all NIST PQCRYPTO candidates.
For instance:

A key encapsulation mechanism is a triple of algorithms $\mathcal K = (\mathsf{KeyGen}, \mathsf{Encaps}, \mathsf{Decaps})$ and a corresponding key space $K$. …

- The probabilistic encapsulation algorithm $\operatorname{\mathsf{Encaps}}(\mathit{pk})$ takes as input a public key $\mathit{pk}$ and outputs a ciphertext $c$ as well as a key $k \in K$.

—Nina Bindel, Jacqueline Brendel, Marc Fischlin, Brian Goncalves, and Douglas Stebila, “Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange”, in Jintai Ding and Rainer Steinwandt (eds.), proceedings of Post-Quantum Cryptography: 10th International Conference, PQCrypto 2019, Springer, Lecture Notes in Computer Science, vol. 11505, ISBN 978-3-030-25510-7, ISSN 0302-9743.

A cursory search of the cryptology eprint archive will reveal arbitrarily many other papers in the decades since it was introduced that all agree on the definition of key encapsulation.

You may find the use of the word linguistically distasteful, but the literature is consistent on its technical meaning.