Fuxt API - Posts Include Param

[dChiamp]

What

Two changes, deployed together:

1. include param on GET /wp-json/fuxt/v1/posts

Fetch specific posts by ID in a single request:

GET /wp-json/fuxt/v1/posts?include=12,34,56&fields=acf,terms

Pearl's favorites feature stores favorited post IDs client-side and needs to rehydrate a mixed list of posts (event, music, shop, dine-and-drink, post) in one request.

• include accepts a comma-separated list of post IDs (sanitized via wp_parse_id_list, capped at 100 to match the per_page maximum).
• When include is set and no post_type is given, the query spans all fuxt-exposed post types (Utils::get_post_types()) instead of defaulting to post — deliberately not post_type => 'any', which would silently exclude CPTs registered with exclude_from_search.
• Results preserve the given ID order (orderby => post__in) unless the caller explicitly sets orderby.
• posts_per_page is set to the ID count so schema defaults (per_page=10) don't truncate; post_status => publish and ignore_sticky_posts are forced.
• Explicit post_type still narrows results; unknown IDs are simply omitted.

2. Project Images endpoint (commits previously-unversioned production code)

/fuxt/v1/project-images (upload + list, API-key auth, rate limiting) has been running on Pearl's production WP but was never committed to the repo. Deploying this branch's first commit alone removed class-rest-project-images-controller.php from the server while the deployed class-plugin.php still instantiated it, causing a site-wide fatal (Class "FuxtApi\REST_Project_Images_Controller" not found). The outage was fixed by restoring the file on the server; this commit makes the repo the source of truth so deploys from main can't re-break it.

Worth a quick sanity review of the project-images auth/rate-limit logic since it was authored outside this PR.

Version bumped to 0.1.5. Needs to be deployed to Pearl's WP install (both commits together) before the frontend favorites page ships.