Add rollback (w db) steps to upgrade page

[Rachael-Graham]

for kagent-dev/kagent#1963

[iplay88keys]

I think the steps laid out here are slightly easier and can be combined with this section. For example, I'm not sure you need to checkout the migration files locally if you don't want.

[iplay88keys]

Can you clarify this? I'm not sure why they wouldn't line up. I believe we use the same versioning for the git tags as we do for the release.

[iplay88keys]

For something like: https://github.com/kagent-dev/kagent/tree/v<target-version>/go/core/pkg/migrations/core/, would it be better to put the rollback version ("target version") in step 1's export as an env var and reference it here?

So something like:

export CURRENT_VERSION=<current-version>
export ROLLBACK_VERSION=<previous-version>

Then use it in the step's text with: https://github.com/kagent-dev/kagent/tree/v${ROLLBACK_VERSION}/go/core/pkg/migrations/core/

I feel like it is clearer to provide env vars instead of something like <rollback-migration-version> or <target-version> in general, but maybe that's just me. I think it probably matters more in the bash blocks, but just a suggestion.

[iplay88keys]

Maybe we ground this in a real example if we are doing it in the docs

[iplay88keys]

So let's say you go back from 0.9.7 to 0.9.6 (where 0.9.7 added migration 5 to the core track).

You would have goto 4 in that case.

[Rachael-Graham]

I changed this to a real set of versions but just fyi since this is only available in 0.9.x and later, but 0.10.x isnt actually released yet, i cant show a minor-version rollback yet from 0.10.x to 0.9.x - lmk if that isnt alright

[artberger]

maybe a hint why it's goto 4

Suggested change

	For example, `v0.9.9` has migrations up to `000005_a2a_protocol_version.up.sql` and `v0.9.3` has migrations up to `000004_feedback_single_pk.up.sql`. To roll back from `v0.9.9` to `v0.9.3`, you set `CURRENT_VERSION=0.9.9`, `ROLLBACK_VERSION=0.9.3`, and run `goto 4`.
	For example, `v0.9.9` has migrations up to `000005_a2a_protocol_version.up.sql` and `v0.9.3` has migrations up to `000004_feedback_single_pk.up.sql`. To roll back from `v0.9.9` to `v0.9.3`, you set `CURRENT_VERSION=0.9.9`, `ROLLBACK_VERSION=0.9.3`, and run `goto 4` because you want to go back to migration sequence 4 (v0.9.3's `000004`).

[iplay88keys]

One more thing, you need to roll back one minor at a time and there might be data loss going more than one minor back as our approach is backwards compatibility of one minor version back.

[Rachael-Graham]

Added in a note on 133 and in the original desc on 94

[artberger]

maybe a hint why it's goto 4

Suggested change

	For example, `v0.9.9` has migrations up to `000005_a2a_protocol_version.up.sql` and `v0.9.3` has migrations up to `000004_feedback_single_pk.up.sql`. To roll back from `v0.9.9` to `v0.9.3`, you set `CURRENT_VERSION=0.9.9`, `ROLLBACK_VERSION=0.9.3`, and run `goto 4`.
	For example, `v0.9.9` has migrations up to `000005_a2a_protocol_version.up.sql` and `v0.9.3` has migrations up to `000004_feedback_single_pk.up.sql`. To roll back from `v0.9.9` to `v0.9.3`, you set `CURRENT_VERSION=0.9.9`, `ROLLBACK_VERSION=0.9.3`, and run `goto 4` because you want to go back to migration sequence 4 (v0.9.3's `000004`).

[artberger]

maybe a hint, if this is the same number as the goto previously I'm assuming?

Suggested change

	4. Open the core migration directory for your rollback version and save the sequence number of the highest-numbered file in an environment variable.
	4. Open the core migration directory for your rollback version and save the sequence number of the highest-numbered file in an environment variable, such as `4` from the previous v0.9.3 `goto 4` example.