Hi! Thanks for the great library. Maybe I'm doing something wrong but when I run the post example, I get the following error:

Error: request error: HTTP status client error (422 Unprocessable Entity) for url (https://cohost.org/api/v1/login)

Caused by:
    HTTP status client error (422 Unprocessable Entity) for url (https://cohost.org/api/v1/login)

I've double checked that the provided email/password/page is correct, as well as tried using other pages to authenticate, but I've had no luck. Looking at the login flow via mitmproxy seems to indicate that the login endpoint hasn't changed, so I'm unsure why the 422 error. Still (to me) sounds like the API has had some minor changes, but I can't figure out any as the login code seems to match what I'm seeing using the website under mitmproxy (I'd love to give screenshots/more info, but unfortunately I don't trust my ability to redact sensitive data from an authentication flow trace due to being 3 am, but if you need more info later I can provide it)

• API is now more strict about requiring an integer for contentLength. Numeric strings are no longer accepted.
• width and height are now available (albeit optional) fields. Including these is preferred. I included an implementation for this, although I am amateurish at rust so my way of getting around borrowing path after moving (clones!) is probably incorrect. Would love to know what's actually idiomatic here.

Tested this works as expected with no changes required for examples/post.rs.

Hopefully this API looks okay. My main thought would be that it might not be desirable to re-use the existing post type; if that's true, I'm happy to split that off into a separate read-specific Post type.

In addition, there's the problem of share trees. I'm tempted to provide an option that doesn't deserialize it in whole. However, because it's not permitted in the API to get a single post by ID, we can't just provide the share tree IDs and leave it at that. As I see it, the options are:

• always provide the entire share tree, despite it probably often not being used,
• have a generic parameter on ApiPost that allows selecting whether or not to include the post share tree, using a custom Serde deserialize implementation, or
• have seperate ApiPost and ApiPostWithShareTree types altogether.

Personally, I favor the latter.