Add MCP Hub backend and frontend community plugins

[dividduang]

Summary

Register the paired community MCP Hub plugins via HTTPS submodules:

Plugin	Repository	Version	Pinned commit
Backend mcphub	https://github.com/dividduang/mcphub	1.0.0	5f1b545699b8db530f7b9d4fa3a5256f85b9b33b
Frontend mcphub_ui	https://github.com/dividduang/mcphub_ui	1.0.0	f7ee48d52ba6d74466041af0128d38f981c4ca3d

Both submodules track main. This PR only changes .gitmodules and adds the two plugin gitlinks; it does not change index generation code or generated marketplace data.

Plugin purpose

MCP Hub provides fixed PyPI and Hacker News requests-based crawler tools, per-user tool applications/grants, and independently scoped MCP bearer keys. Tools are filtered and authorized per key at runtime. The paired FBA UI plugin provides the catalog, application/approval flow, and key management.

Publication checklist

• Both repositories are public and use the documented backend/frontend naming conventions.
• Plugin contents are located at repository root, rather than inside an extra plugin directory.
• Backend has plugin.toml, README.md, and __init__.py; frontend has plugin.toml.
• Manifests declare version 1.0.0 and required metadata.
• Backend includes MySQL initialization/destruction SQL (including snowflake variants).
• READMEs document installation/configuration, usage, uninstall, issue reporting, and compatibility limitations.
• HTTPS URLs are used for both submodules.
• Official index validator executed locally: pnpm validate mcphub mcphub_ui → 2 passed, 0 failed.

Compatibility and verification boundaries

• Backend currently targets Linux, MySQL 8.0.16+, Redis, and FBA application-level setup/lifespan hooks. Single execution instance only; not a distributed quota implementation.
• Pinned MCP dependencies must be merged into the host project's own dependency lock. No host core files are silently patched. The original integration environment additionally supported FBA_PLUGIN_DEPENDENCIES_LOCKED; the README explicitly states that this host-core capability is not included in the standalone plugin.
• MCP access uses private bearer keys, not OAuth. Fixed upstreams only; arbitrary URL/code upload is not supported.
• The original development workspace exercised authorization/revocation, real public upstream requests, browser flows, and 220 successful concurrent calls against a controlled local upstream. That capacity result is not a public-site throughput guarantee or a claim of compatibility with every FBA/client version. Application behavior was not rerun as part of this index-only PR.
• Original frontend typecheck/build passed, but full-host lint was not green: an existing API Key empty interface blocked Oxlint, and Oxfmt/ESLint Vue formatting rules conflicted. The frontend README discloses these limits; this PR does not alter host lint rules.

Please review the pair for community marketplace inclusion. Submission is not a claim of marketplace approval.

[dividduang]

CI note: the Validate Plugin TOML job failed at checkout, before plugin validation ran. actions/checkout refused to check out fork PR commit 09fab24 from a pull_request_target workflow (allow-unsafe-pr-checkout defaults to false). Log: https://github.com/fastapi-practices/plugins/actions/runs/37011547710/job/110852228991 . Locally, the unchanged official validator ran against both public submodules: pnpm validate mcphub mcphub_ui → 2 passed, 0 failed. This PR intentionally does not weaken checkout protections or change workflows. Maintainer-side resolution should prefer untrusted validation under pull_request with read-only permissions and a separate trusted reporting step, rather than opting into unsafe checkout in the privileged workflow. Remote validation remains failed; no claim of CI success.