Requirements 1.1 and 1.3 are incompatible; there's nothing that software can do which an admin of that software cannot do.
If you don't need the server to be able to decrypt the data at all, that works fine and is called end-to-end encryption (E2E) and is used for a wide variety of very secure tools. With E2E, only the client can decrypt the data; the server can only receive, store, and transmit encrypted blobs with no access to their contents.
Requirement 1.2 can be met by having the server store a public key for each user, and - when it wants to encrypt data to that particular user - first creating a new symmetric key, encrypting data with that key, and then encrypting ("wrapping") the symmetric key with the user's public key and storing the encrypted data and wrapped symmetric key together. The user, which is the only entity with access to the corresponding private key, is the only entity that can unwrap the symmetric key. However, this still requires that the server be trusted, or else it (or a malicious admin) might do something like also wrap the symmetric key with their own public key, or just store the symmetric key (or the data itself) in plain text somewhere.
Requirement 2.1 is fundamentally impossible if there is no fully-trusted agent to do the decryption for you. If the server is doing the decryption itself (and is not fully trusted, because the admin isn't fully trusted) then the server/admin can steal the decryption key and hold onto it for later use. You can mark a key as "don't use after this date" but there's no (known) way to mathematically enforce such an inherently non-mathematical concept and cryptography is just math. Enforcement is up to the agent doing the decryption, and the key expiry is nothing but a suggestion.
Requirement 2.2 can be achieved by transmitting the key over a local network or Bluetooth, or encoding it as a QR code and displaying it on the screen, or other such methods. For maximum security, though, the key should be encrypted using a user-supplied password and decrypted on the other end, or better yet transmitted over an encrypted channel using an ephemeral key with the passwords used only to verify the ephemeral key parameters (this is known as "forward secrecy" and prevents an attacker from decrypting the key even if they recorded all the network traffic and later learn the password that was used).
Given the questions that you are asking, you almost certainly do not have enough security knowledge to design this system securely, or securely implement even a secure design. Designing new cryptosystems is hard, as is implementing them. For example, the SSL/TLS protocol is decades old, designed by people who theoretically know what they're doing, and has been through 6 different published versions because people keep finding weaknesses in the old ones... and that's just the design; the actual implementations in libraries like OpenSSL have had numerous and occasionally massive vulnerabilities.
If you have a specific use case in mind, there may exist well-reviewed software that already provides it (for example, nobody should be attempting to roll their own password manager unless they fully understand how the existing ones work and have some specific improvement they want to make but can't just get LastPass/1Password/etc. to implement it). Don't re-invent the wheel if you don't have to, especially if you're not quite sure how wheels work and want them to do several incompatible things.
If you're trying to create something that's totally new, document it and put out the document in a Request For Comments (RFC) so the industry can try to poke holes in the idea, and then after the design is done, open-source the code you write so that the industry can review your implementation. If the design and/or code must remain proprietary, you're probably not going to be able to achieve as good of security but you should still hire a cryptographic security expert (perhaps as a consultant) to review the design and implementation.
