Design an in-memory recipe manager with four levels of functionality. No UI is required; focus on clean APIs, data structures, and edge-case handling. ### Level 1: Basic recipe management Support creating, reading, updating, and deleting recipes. Each recipe contains: - `name` - unique string identifier - `ingredients` - list of ingredient names - `steps` - ordered list of instructions ### Level 2: Search by ingredient Add a query that returns all active recipes containing a given ingredient. ### Level 3: Users and sorting Introduce a `User` concept. - Every create, update, or delete operation must be associated with a user. - A recipe should record which user most recently modified it. - Support listing recipes sorted by a caller-specified key, such as recipe name or number of ingredients, in ascending or descending order. ### Level 4: Version history Add version control for recipes. - Every create and update must generate an immutable version snapshot. - Each version should record the recipe content, version number, timestamp, and editing user. - Support listing all versions of a recipe. - Support searching version history, at minimum by recipe name and editor. - Historical versions must remain accessible even if the active recipe is later deleted. Describe the class design, core APIs, data structures, and how you would handle corner cases such as duplicate recipe names, ingredient normalization, and deletes with version history.