Accept commit message as a parameter for commit-specified-message variants (enable URI / external invocation)

What

Currently, the *-specified-message command family (commit-specified-message, commit-staged-specified-message, commit-push-specified-message, commit-amend-staged-specified-message, commit-smart-specified-message) collects the commit message via an interactive CustomMessageModal. There's no way to provide the message at invocation time as a parameter.

Proposal: allow the message to be supplied as a parameter on invocation. When the parameter is present, skip the modal and use the supplied message verbatim. When absent, current behavior (open modal, prompt user) is preserved.

Two concrete delivery paths, pick whichever fits your design:

1. Variant A: second command per existing command: add commit-specified-message-from-data, commit-staged-specified-message-from-data, etc., each reading the message from evt.data / context arg passed by the invoker. Preserves the existing UI-driven commands unchanged.
2. Variant B: optional parameter on existing commands: extend each *-specified-message command's checkCallback / callback to read an optional args / data field from the invocation context; fall back to modal when absent. Smaller surface, but changes the existing command behavior under invocation.

Why

The current model assumes a human in the Obsidian UI is the source of the commit message. Three real workflows that break under that assumption:

1. Automation via Advanced URI: Advanced URI's commandid action can already invoke any command, but its documented parameter set (https://vinzent03.github.io/obsidian-advanced-uri/actions/commands) (vault, filepath, line, mode, confirm) has no slot for passing arbitrary command input. Today, obsidian://advanced-uri?commandid=obsidian-git:commit-specified-message opens the modal and waits. With this change, a future Advanced URI release (or a small companion change there) could pass data= through to obsidian-git, enabling fully scripted invocations.
2. Plugin-to-plugin integration: Other Obsidian plugins that want to drive commits (export pipelines, automation plugins, snapshot tools) currently have two options: monkey-patch into app.plugins.plugins['obsidian-git'] (no stable contract; field renames break consumers across versions) or open the modal and try to automate the user input (brittle). A first-class "commit with this message" command would be the stable contract.
3. External tooling: workflows where an external script (build system, CI runner, headless agent, indexing pipeline) wants to commit a known, machine-greppable message and exit. The script can already open Obsidian via URI and trigger the command, but cannot today specify the message. The auto-commit-message template ({{numFiles}} {{date}} {{hostname}}) is the only currently-scriptable path, and template substitution can't produce structured subjects like [ProjectX checkpoint:cp-002 conversation:abc-def] that consumers need for grep / log filtering.

The common ask: the same workflows that already use obsidian-git interactively for vault management should be scriptable when the user wants to integrate another tool. Today they can't be, because the message is the missing parameter.

Scope

• Non-goal: changing the default UI behavior. With no parameter, the modal opens exactly as today.
• Non-goal: defining the Advanced URI parameter format. That's an Advanced URI concern; this issue just makes obsidian-git capable of receiving a message when one is provided.
• Non-goal: bypassing modal confirmations on destructive commands. discard-all-changes etc. retain their confirmations.

Compatibility

Adding new commands (Variant A) is purely additive - no existing user, hotkey, or workflow breaks. Variant B is additive at the type level (parameter is optional) and behavior-preserving in the absence of a parameter.

Offer

Happy to PR either variant. My preference is Variant A (additive new commands, zero risk to existing users) but I'll defer to your call on naming and which subset of *-specified-message variants are in-scope. Let me know if there's an approach you'd prefer to see, or if this isn't a direction you want to take obsidian-git in, happy to drop it if so.

Sources

• README (https://github.com/Vinzent03/obsidian-git)
• Command IDs (src/commands.ts (https://github.com/Vinzent03/obsidian-git/blob/master/src/commands.ts))
• Advanced URI command parameters (docs (https://vinzent03.github.io/obsidian-advanced-uri/actions/commands))