forgejo: add dump archive integration

[IvanchitorJR]

Refs PlakarKorp/hub#4.

Summary

Adds a community Forgejo integration that uses Forgejo's built-in dump tooling:

• forgejo:// importer invokes forgejo dump --file ... --type ... --quiet and stores the resulting archive in the snapshot.
• Snapshot includes /forgejo-dump.<type> plus /manifest.json metadata.
• forgejo:// exporter materializes snapshot records into a local output directory so the dump archive is ready for Forgejo's documented restore workflow.
• Adds manifest metadata, JSON schemas, README usage docs, and build targets.

Validation

• gofmt on new Go files
• go test ./...
• go build -v -o forgejoImporter ./plugin/importer
• go build -v -o forgejoExporter ./plugin/exporter
• git diff --check -- forgejo

Note: I validated compilation and package-level behavior locally. I did not run an end-to-end live Forgejo container restore in this environment.

[IvanchitorJR]

Validation update: I added focused importer/exporter unit tests and tightened exporter path handling so restore rejects .. traversal attempts instead of normalizing them silently.

Re-ran locally after the update:

• gofmt on new Go files
• go test ./...
• go build -v -o forgejoImporter ./plugin/importer
• go build -v -o forgejoExporter ./plugin/exporter
• git diff --check -- forgejo

[IvanchitorJR]

Small follow-up: I added an importer flow test that uses a fake forgejo command to verify the integration actually invokes forgejo dump, consumes the generated archive, emits /manifest.json, and emits /forgejo-dump.zip with ACK handling.

Re-ran locally after the change: go test ./..., importer build, exporter build, and git diff --check -- forgejo.

[Alex-Parejo]

One small hardening point: dump_type is passed to orgejo dump --type without validation, while �rchiveExtension() falls back to .zip for unknown values. So a typo like dump_type=tarz would run orgejo dump --type tarz but name/metadata the snapshot as orgejo-dump.zip. I would either validate dump_type against the supported set in NewImporter/schema or make �rchiveExtension return an error for unknown values, so failed config is explicit instead of producing mismatched archive metadata.

[Alex-Parejo]

Clarifying my previous review comment, which got mangled by shell escaping:

dump_type is passed to forgejo dump --type without validation, while archiveExtension() falls back to .zip for unknown values. So a typo like dump_type=tarz would run forgejo dump --type tarz but name/metadata the snapshot as forgejo-dump.zip.

Suggestion: validate dump_type against the supported set in NewImporter/schema, or make archiveExtension return an error for unknown values.

[IvanchitorJR]

Thanks for catching that. I pushed b32c010 to validate and normalize dump_type before it reaches forgejo dump.

Changes:

• accept only Forgejo's documented dump formats: zip, tar, tar.sz, tar.gz, tar.xz, tar.bz2, tar.br, tar.lz4, tar.zst
• reject unknown values at importer construction instead of silently naming them .zip
• add schema enums and README-supported values
• add tests for unknown dump types and normalization

Re-ran locally: gofmt, go test ./..., importer/exporter builds, and git diff --check -- forgejo.