[codex] prepare 1.0.0 release

[samlaycock]

Summary

Prepares Litz for the intended 1.0.0 public release posture.

• Versions the pending Changesets entries into the generated 1.0.0 release notes.
• Updates package.json from 0.7.0 to 1.0.0.
• Replaces the README production-candidate status with stable-release language.
• Expands the 1.0.0 changelog section with release scope and known limitations.

1.0 Scope

This release establishes Litz as a stable client-first React framework for Vite with explicit defineApp(...) registration, server boundaries, route loaders and actions, reusable server-backed resources, raw API routes, and RSC/Flight-backed view(...) responses.

The consumed changesets include custom data serializers, explicit app discovery improvements, duplicate path diagnostics, dev middleware parity fixes, safer malformed internal request handling, API HEAD/Allow behavior, JSX route projection, namespace import discovery, loader batching behavior, resource action revalidation and redirects, client prefetch cancellation, and release workflow e2e requirements.

Known Limitations

• The production browser build still follows the current single-client-entry model.
• Local e2e validation requires Playwright browsers to be installed before running bun run test:e2e.

Validation

• bun fmt
• bun lint:fix
• bun lint
• bun test
• bun typecheck
• bun run test:e2e

Closes #190

[greptile-apps]

Greptile Summary

This PR prepares the litzjs package for its 1.0.0 stable release by consuming all pending Changeset entries, manually authoring the 1.0.0 changelog section, bumping package.json from 0.7.0 to 1.0.0, and updating the README status line from "production candidate" to stable-release language.

• Fifteen changeset files (one minor, fourteen patches) are deleted after their descriptions are folded into the new ## 1.0.0 CHANGELOG section under the appropriate Minor Changes and Patch Changes headings.
• The ### Major Changes entry is hand-crafted (no commit hash) to document the stable graduation intent, since no individual changeset was tagged major; the version jump from 0.7.0 to 1.0.0 was applied directly to package.json rather than through changeset version.

Confidence Score: 5/5

Safe to merge — all changes are documentation, changelog, and a version bump with no functional code modifications.

The diff touches only the CHANGELOG, README status line, package.json version field, and deleted changeset files. There are no runtime or build-logic changes. The one observation is that the hand-crafted Major Changes entry omits any statement about breaking changes, which could leave upgrading users uncertain, but this does not affect runtime correctness.

CHANGELOG.md — the Major Changes section would benefit from explicitly stating whether any breaking changes exist relative to 0.7.x.

Important Files Changed

Filename	Overview
package.json	Version bumped from 0.7.0 to 1.0.0; no other changes
CHANGELOG.md	New 1.0.0 section added with hand-crafted Major Changes entry (no commit hash) and automatic Minor/Patch entries from consumed changesets; major section describes release preparation rather than breaking API changes
README.md	Single-line status update from "production candidate" to stable 1.0.0 release language

_{Reviews (1): Last reviewed commit: "chore: prepare 1.0.0 release" | Re-trigger Greptile}

[greptile-apps]

Major Changes section describes release preparation, not breaking changes

The ### Major Changes entry explains that metadata and release notes were prepared, but does not state whether there are any breaking API changes relative to 0.7.x. For consumers upgrading from a 0.x line, a major-version changelog entry is the first place they look to understand migration cost. Adding a short note such as "This release contains no breaking changes relative to 0.7.0 — the major bump marks the graduation to stable" would make the upgrade story immediately clear.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!