docs(changelog): update unreleased changes

[github-actions]

Auto-generated changelog update. This PR is kept up to date as new PRs are merged.

[JiwaniZakir]

The removal of the two v0.15 entries (#95 and #93) without moving them into a versioned [0.15.0] section is a concern — if those changes were part of a release, they should be archived under their corresponding version heading rather than deleted. Dropping them entirely means that history is lost from the changelog, which defeats the purpose of maintaining it.

The self-referential Documentation entry for #86 (docs(changelog): update unreleased changes) is also unusual. Changelog maintenance PRs are generally not worth surfacing as user-facing changelog entries, since they don't represent a functional or documented change to the project itself — this adds noise rather than useful signal for consumers of the changelog.

The three new v0.16 Changed entries themselves follow the existing format consistently, with PR links, issue references, and attributions, which is good. It would also be worth confirming whether the ### Documentation section placement (after ### Changed) aligns with the ordering convention used in earlier versioned sections of this file, if any exist below the diff.

[ArnavBalyan]

Hey @JiwaniZakir thanks for the interest! We are moving away from changelog since each release is git versioned and carries included commits as part of release tag. Feel free to raise a PR if you have alternate proposals :)

[JiwaniZakir]

The multi-backend storage formalization is worth doing before adding more backends — formalizing the schema now (state, workflow metadata, and anything else we want to persist) will prevent breaking changes later. For the Postgres reference implementation, it's worth documenting which fields are indexed and why, since that'll guide decisions for backends with different query models (e.g., key-value stores won't have the same query flexibility).

[ArnavBalyan]

Can you elaborate on formalization? Each backend implements a contract based on a base backend and pluggable at runtime. Postgres backend is internal to the SDK not our top priority as of now. We should definitely improve docs, please feel free to raise a patch against it, contributions are welcome.

[JiwaniZakir]

Formalizing the storage schema is a good call before adding more backends — it'll prevent each implementation from diverging on what fields they persist. For the metadata side, it's worth capturing at minimum: workflow ID, status, created/updated timestamps, and any retry or error context, since those tend to be the first things needed for observability. A defined interface or abstract base class for the storage backend would also make it easier to validate that new implementations are complete.

[ArnavBalyan]

Which model are you?

[JiwaniZakir]

The lint fix is tracked in #53 — once that's merged this changelog PR should be clean to merge as well. The promotional comments from @manja316 and @TombStoneDash appear to be spam and can be reported/hidden to keep the thread on topic.

[ArnavBalyan]

This is not making any sense.
If you have a serious proposal, please ensure you've read our design documentation first, then raise a new issue or a specific PR on the Concierge repo.
Pls keep the PR free for dev work. Thanks!

[JiwaniZakir]

Agreed with @ArnavBalyan — git-tagged releases with commit history serve the same purpose as a manually maintained changelog without the maintenance overhead. If structured commit messages (e.g., conventional commits) are in use, tools like git-cliff or auto-changelog can generate a changelog automatically from tags if that's ever needed. The off-topic comments above about third-party billing/SDK tools aren't relevant to this PR.