reverse-engineered fix for update/create/delete recipes

[aullrich2013]

Title

Fix recipe save/delete persistence by matching current AnyList web payloads

Summary

This patch fixes recipe persistence for the unofficial AnyList client.

Before this change, recipe operations such as:

• createRecipe(...).save()
• editing an existing recipe and calling save()
• recipe.delete()

could return without error but fail to persist after a fresh read.

Root cause

The current recipe operation payload no longer matches what the AnyList web client sends.

The working web payload differs in a few important ways:

1. Recipe operations include a real userId in metadata.
2. Recipe writes do not populate recipeIds.
3. Save operations use a sparse recipe payload.
4. Remove operations include timestamp and recipeDataId on the nested recipe payload.
5. Ingredient payloads include identifier and isHeading.

What this patch changes

• Derives uid from the JWT sub claim after login / token refresh.
• Updates Recipe._encode() so recipe payloads match the current browser behavior more closely.
• Stops sending recipeIds for recipe operations.
• Includes timestamp and nested recipeDataId for remove-recipe.
• Preserves ingredient identifiers and isHeading when encoding ingredients.

Validation

Validated against the live AnyList web app by capturing browser traffic and comparing the protobuf request bodies.

Confirmed working end-to-end after the patch:

• create recipe -> fresh search finds it
• update recipe note -> fresh read shows the new note
• delete recipe -> fresh read returns null

Notes

This is based on observed current web payloads from /data/user-recipe-data/update. The previous implementation appears to reflect an older contract that now succeeds superficially but does not persist recipe changes.