[Bug]: nova bump should require explicit override when Git inference is unavailable

[stiwicourage]

Summary

nova bump should not silently fall back to Patch with Commits: 0 when Git-based bump inference is unavailable.

The current behavior is user-hostile because it produces a plausible version plan even when Nova did not actually infer the label from Git history. That can lead to an incorrect version bump.

This is a follow-up to #174.

Steps to reproduce

1. Use a project with a project.json version such as 1.5.4-preview.
2. Run nova bump -w in a case where Nova cannot infer the bump label from Git history.
   • one example is a nested project where Git resolves from a parent repository but Nova does not detect it correctly yet ([Bug]: nova bump should detect parent Git repositories for version inference #174)
   • another example is a real non-git scenario such as an example/template flow where no Git repository exists at all
3. Observe the planned version.

Expected behavior

Nova should use a compatibility model that is safe and explicit for users:

1. If Git can be resolved from the current folder or a parent folder, Nova should use that repository for bump inference (covered separately by [Bug]: nova bump should detect parent Git repositories for version inference #174).
2. If Git-based inference is genuinely unavailable, Nova should not silently present a normal-looking inferred patch plan.
3. In that non-git / no-inference case, Nova should clearly explain that bump inference is unavailable and require an explicit opt-in such as -OverrideWarning, --override-warning, or -o before proceeding with a fallback patch bump.
4. That preserves compatibility for valid non-git workflows (for example shipped example projects or template flows) while making the risk explicit.

Actual behavior

Nova currently falls back to a patch plan with Commits: 0, which makes it look like a valid inference result even when commit history was not used:

What if: Performing the operation "Update module version using Patch release label" on target "project.json".
Version plan: 1.5.4-preview -> 1.5.4 | Label: Patch | Commits: 0

That output hides the distinction between:

• "Nova successfully inspected Git history and the result is Patch"
• "Nova could not infer the label at all, so it fell back"

NovaModuleTools version

2.3.0

Where did you hit the issue?

nova CLI

Command or cmdlet

nova bump -w

Relevant output or logs

PWD: /Users/stiwi.courage/workspace/arbejdstilsynet/Tools/AzureDevOpsAgentInstaller

DIRECT .git: no
GIT TOPLEVEL: /Users/stiwi.courage/workspace/arbejdstilsynet/Tools
GIT DIR: /Users/stiwi.courage/workspace/arbejdstilsynet/Tools/.git

What if: Performing the operation "Update module version using Patch release label" on target "project.json".
Version plan: 1.5.4-preview -> 1.5.4 | Label: Patch | Commits: 0

Relevant project.json snippet

{
  "Version": "1.5.4-preview"
}

Operating system

macOS 26.4.1

PowerShell version

7.5.4

Shell

PowerShell

Installation method

Installed nova launcher

Regression?

Not sure

Additional context

The root cause for one case is repo detection (#174), but this issue is specifically about fallback handling and user experience when inference is unavailable.

I checked the code path and Nova currently:

• returns no commit messages when .git is not directly inside the project root
• then falls back to Patch
• and reports Commits: 0

That is too easy to misread as a legitimate inferred result.

A good fix would preserve non-git use cases, but make the fallback explicit and intentional instead of silent.