feat(social): add social graph and moderation UI/protocol layer

[mxrtins04]

closes #262

What changed

Implements the first version of the social graph and moderation UI/protocol layer per the design-first requirement in #262.

Phase 1: design document (social-graph-moderation.md) covering the connection data model, privacy rules for who can see a member's connections, and the moderation state machine (report, review, action, appeal, reinstatement/uphold), written to mirror guildpass-core's deferred appeals/reinstatement workflow rather than diverging from it.

Phase 2: implementation built against that design.

• API schema (openapi.json) extended and regenerated (sync-api-types.js, types.ts) to add connection, block, report, and moderation-state types.
• API logic layer (live.ts, mock.ts, query-keys.ts) added for social graph and moderation queue data access.
• Member profile page (app/members/[address]/page.tsx) now shows connections respecting the documented privacy rules.
• Admin moderation queue page (path to be confirmed, see note below) added for reviewing reports through the full appeal/reinstatement lifecycle.

Files added/modified

• docs/social-graph-moderation.md (design doc)
• openapi.json
• sync-api-types.js
• types.ts
• live.ts
• mock.ts
• query-keys.ts
• app/members/[address]/page.tsx
• [second page.tsx path pending confirmation, likely app/admin/moderation/page.tsx]

Security / rollback notes

• Connection visibility is enforced per the documented privacy rules, directly addressing the abuse case named in the issue: a user cannot be harassed via a public connection list, since visibility is scoped per viewer and blocks suppress visibility in both directions.
• Moderation state machine changes are additive: new queue, new types, no existing member or auth data model is altered.
• Rollback: revert the commit. No migration of existing member data is required, since this introduces new surfaces rather than modifying existing ones.

Test output

[paste full lint/test/build output here]