P2: Index state changes for the activity feed

Why

The activity feed — the repository’s Activity tab, the instance-wide one, and the home page’s per-repository feed — finds closed, reopened and merged events by reading the last 200 metadata commit subjects. That is one git log process per repository per request: on the instance home with N repositories it is N processes, and it is the last git call those pages make for data the index can hold.

Every other list and count was moved to index.db in #113; state changes were left behind because they come from commit subjects rather than the tree.

Scope

• A state_changes table derived by the same refresh: a delta reads the commits in its range, a rebuild reads the whole metadata branch. Rows are keyed by the commit, so a retried or overlapping refresh cannot duplicate an event, and an ordinal keeps two changes in one second in branch order.
• Store.StateChanges returns the feed’s events newest first; the web feed reads it and falls back to the metadata log for a server without an index or a failed read.
• git.Repo.Log and CommitsBetween treat a limit of zero as “no limit” (the rebuild needs all of history); metadata.ParseStateSubject is exported so the index derives the events without a second copy of the format.

Acceptance

• The activity, instance-activity and home pages start no metadata log for data; the remaining calls are the latest commit, tags, and the branch the page shows.
• Closing and reopening an issue, and closing a change, appear in the feed from the index.
• An incremental refresh and IndexRepo produce identical events, and repeated refreshes do not duplicate one.
• A server without an index still shows the feed from git.

Notes

The latest commit and the tag list still come from git: they are content, not a derived row this change is about. Schema version 7 rebuilds each repository on its first read after upgrade.