Revert PR #21 merge for reviewer-controlled merge flow

[KareemN1936]

This reverts PR #21's merge commit (a64edb4) so the relationship lore graph work is no longer merged by me and can return to the normal reviewer-controlled merge flow.

Context:

• I merged Feature/m2 relationship lore graph kareem #21 after it was approved and green, but Kareem clarified that the reviewer/DR should be the one to merge approved PRs.
• This PR restores that process through a normal PR revert rather than rewriting develop history.
• After this lands, Feature/m2 relationship lore graph kareem #21's feature branch remains available for the reviewer/DR to merge when they choose.

Also done separately:

• Reset feat(ui): add contribution editor workflow #20 back to 0efbf64, so feat(ui): add contribution editor workflow #20 no longer carries Feature/m2 relationship lore graph kareem #21's merged code through its branch.

Note: the revert is large because #21 was a stacked branch and its merge commit carried the worlds/lore relationship stack into develop.

[github-actions]

Vercel preview is ready:

https://hivelore-avrj0w63d-kareemn1936s-projects.vercel.app

Commit: 7e9710e

[mcfarhat]

Verified and approving.

I checked the revert is exact rather than taking it on trust: applying this to develop produces a tree byte-identical to 457fffe, the commit immediately before #21's merge. No collateral — the docs change from #23 survives intact, and nothing else is touched.

Doing it as a revert PR rather than rewriting develop history was the right call, and resetting #20 off the merged code was the right follow-through. Thank you for spotting it and correcting it yourself.

On the process, so it's written down once and we move on: merging is the reviewer's call, including when a PR is approved and green. An approval means "I have no further changes to ask for" — it isn't a green light to merge, because merge order is often carrying information the author can't see. That was the case here: #22 has to land first, since it carries the migration baseline repair and the test harness. Landing #21 first meant everything after it would merge under CI that can't fail.

The concrete cost, measured:

#22 into develop BEFORE #21 landed : CLEAN
#22 into develop after             : CONFLICTS in 5 files
#20 into develop BEFORE #21 landed : CLEAN
#20 into develop after             : CONFLICTS in 4 files

Nine conflicting files across two PRs that were clean beforehand — including Perla's, which she'd have had to resolve without knowing why. That's the thing merge sequencing protects against.

I'll also own my half: I approved #21 and left it sitting without saying I was deliberately holding it. From your side that looked like an approved, green PR nobody was acting on. From now on, when I approve something I'm not merging immediately, I'll say so on the PR with the reason.

What happens next:

1. This merges now — develop returns to pre-#21 state and both #22 and #20 go back to clean.
2. #22 lands first, once its three remaining items are fixed.
3. I merge #21 — your branch is untouched and it was a fast-forward before, so nothing is lost.
4. Then #20, once the TimeoutError fallback and the default request timeout are in.

#21 stays approved. This is a sequencing correction, not a reassessment of the work.