fix(typedoc): documentation & API completeness fixes

[SpacingBat3]

To-Do List (and changelog)

• Re-export necessary types (most are part of configuration or public methods that are part of API)
  • Re-export *ConfigOptions in makers.
  • Re-export necessary types in publishers.
  • Re-export necessary types in plugins.
    • Re-export neccesary types in Vite plugin.
    • Re-export neccesary types in Webpack plugin.
      • Note: There's a lot of types that might require exposure, it might be worthwhile to discuss it beforehand or re-take it in separate patch set.
• Link external types to upstream documentation.
  • Ensure that Electron Forge does not document ListrTask and document it by linking to upstream documentation.
• Resolve other TypeDoc warnings (if applicable to do so, else ensure they can finally be left as-it-is for the time being).

Acknowledgements

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• The changes are appropriately documented (if applicable).
• The changes have sufficient test coverage (if applicable).
• The test suite passes successfully on my local machine (if applicable).

Description

This PR focuses on TypeDoc fixes to document all types that should be public in API (and, by that definition, also exposes them if they weren't part of package entrypoint) and to avoid documenting types that are external (currently from listr2 package).

The aim for this PR is to restore documentation completeness that was in the past Electron Forge builds but since #3636 it was lacking important documentation references that are needed by users to exactly know how to configure Forge. It is still work-in-progress to achieve this goal, albeit many improvements were already completed and as a result, even current iteration of patch set is ready for discussion.

Alternative changes (to discuss)

• If exposure is not desired, but type should still be documented, it is possible to do so via plugin: typedoc-plugin-missing-exports (previous PRs suggests however this aproach is discouraged).
• Albeit I personally think the documentation separation between projects is desired, it is also possible to document listr2 types as part of respective Forge packages which re-export them.

[MarshallOfSound]

@claude review

[claude]

LGTM — this is a mechanical, low-risk PR consistent with the recent series of "expose *Config" commits already merged (see MakerRpm, PublisherStatic, PublisherBitbucket, PublisherGitHub, VitePlugin commits in history).

Extended reasoning...

Overview

This PR adds export type re-exports for internal config/option interfaces (e.g. MakerDebConfigOptions, MakerFlatpakConfigOptions, MakerRpmConfigOptions, VitePluginBuildConfig/VitePluginRendererConfig, several WebpackPluginEntryPoint* types, StaticArtifact, BitbucketAuth/BitbucketRepository, GitHubRepository) across 9 maker/plugin/publisher packages, plus a rename of MakerFlatpakOptionsConfig -> MakerFlatpakConfigOptions for naming consistency, and a typedoc.json tweak (removes an accidental duplicate packages/plugin/* entry point and adds excludeReferences, externalSymbolLinkMappings, and packageOptions.excludeExternals).

Security risks

None. No runtime logic changes at all — every diff hunk is either a type-only export/re-export or a docs-generation config file. Nothing here touches auth, crypto, network I/O, or file-system permissions.

Level of scrutiny

Low. This is purely additive type surface (public API types becoming importable) and a doc-tooling config fix. I verified the one rename (MakerFlatpakOptionsConfig -> MakerFlatpakConfigOptions) is applied consistently at both its declaration and usage site, with no other references to the old name remaining in the codebase. I also checked that re-exporting a type that was imported via import type (as in VitePlugin.ts) compiles cleanly under this repo's tsconfig, since the repo does not set verbatimModuleSyntax or rely on it erroring in that case — confirmed with a local tsc repro matching this repo's module/target settings. All newly re-exported type names were confirmed to exist in their respective Config.ts source files.

Other factors

This PR is one in an identical sequence of already-merged commits doing the exact same "expose *Config" pattern (visible in recent git log: rpm, github, bitbucket, static, vite maker/publisher packages), so it follows an established, already-reviewed pattern rather than introducing a new one. No CODEOWNERS-restricted or security-sensitive files are touched.