refactor: restructure fmcd as dual library/binary crate

[okjodom]

Reorganize fmcd from monolithic binary into single crate that publishes
both library and binary, following FMCD_LIBBIN.md design.

Changes:

• Move business logic to src/core/ (multimint, operations, services)
• Move API handlers to src/api/ (REST routes, WebSocket handlers)
• Create FmcdCore as central business logic interface
• Add library entry point at src/lib.rs, binary at src/bin/main.rs
• Simplify AppState to delegate to FmcdCore, removing duplication
• Add 'api' feature flag to make web dependencies optional
• Refactor handlers as thin wrappers around core methods

This enables fmcd to be used as a Rust library while preserving all
existing API functionality. Core business logic is now separate from
HTTP concerns, improving testability and maintainability.

[Copilot]

Pull Request Overview

Refactors fmcd from a monolithic binary into a dual library/binary crate to enable use as a Rust library while preserving all existing API functionality.

• Moves business logic to src/core/ module (multimint, operations, services)
• Creates FmcdCore as the central business logic interface with AppState delegating to it
• Introduces feature flag system with optional API dependencies

Reviewed Changes

Copilot reviewed 28 out of 55 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/core/mod.rs	New core business logic module with FmcdCore struct and Lightning operations
src/lib.rs	Updated library entry point with feature-gated API modules
src/state.rs	Simplified AppState to delegate to FmcdCore with backward compatibility methods
src/types.rs	New common types module for library and API sharing
Cargo.toml	Added feature flags making API dependencies optional
tests/integration/api_test.rs	Updated to use accessor methods instead of direct field access
src/api/	Various API handlers updated to use new state accessor methods

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

[nitpick] The core module imports from error module which may contain API-specific error types. Consider creating core-specific error types to maintain clean separation between core business logic and API concerns.

[Copilot]

The types module is only exported when the API feature is enabled, but it contains core types like FmcdResult that should be available to library consumers even without the API feature. Consider splitting types into core and API-specific modules.

Suggested change

	// Only export types when API feature is enabled since they depend on API types
	pub use core_types::*;
	#[cfg(feature = "api")]
	pub use api::rest as router;

[Copilot]

The core module file is very large (859 lines) and contains multiple responsibilities including FmcdCore struct, Lightning operations, and various request/response types. Consider splitting this into separate modules for better maintainability.

[Copilot]

The parameters are prefixed with underscore but not used in the implementation. Consider removing these unused parameters or implementing the custom configuration functionality in FmcdCore.

[Copilot]

[nitpick] The join_federation method takes &mut self but other methods take &self. This inconsistency could be confusing for API consumers. Consider if mutable access is necessary or if the method can be made immutable.

Suggested change

	pub async fn join_federation(&mut self, invite_code: InviteCode) -> Result<FederationId> {
	pub async fn join_federation(&self, invite_code: InviteCode) -> Result<FederationId> {

[Copilot]

[nitpick] The core module depends on the webhooks module which may contain API-specific functionality. Consider whether webhooks belong in the core business logic or should be handled at the API layer.

Suggested change