Clarify release-boundary and version-selection decision policy

[brainboxemb]

Incident

During Migration 011 Forge tooling integration, the repository baseline work was
correctly completed through Forge #33, but follow-up work drifted into Forge API
cleanup and an assumed v0.4.0 release.

The technical release machinery was clear. The decision boundary was not:

• the requested work was to integrate the new shared tool baselines;
• Forge documentation mentioned a later pre-1.0 cleanup/release;
• shared versioning guidance defined exact-revision release mechanics and
  evidence, but did not define how to choose patch/minor/major or when a
  migration should expand into an additional owner release;
• a v0.4.0 Forge release was therefore inferred instead of being derived from
  policy or explicitly aligned with the user.

The out-of-scope Forge API PR was closed without merge and its issue was
reopened.

Why this matters

Autonomous release execution is useful and should remain possible. Requiring
confirmation for every release would add unnecessary friction.

The missing rule is for ambiguous release decisions, not release execution
in general.

We need to distinguish:

1. release mechanics — exact-main qualification, immutable tag/release,
   tagged evidence and consumer adoption;
2. release boundary — whether the current requested/migration scope should
   produce a release at all;
3. version selection — which version number should represent that release.

The current shared documentation defines (1) well, but provides insufficient
guidance for (2) and (3), especially for pre-1.0 libraries and reusable tooling
whose workflow/documentation/interface changes may be structurally large even
when version numbers advance only by a patch.

Desired policy

Preserve autonomous releases when the current repository policy, migration scope
and owner history make the release boundary/version choice sufficiently clear.

When that choice is materially ambiguous:

• do not invent a SemVer rule that is not documented;
• compare the requested scope with the owner/migration plan;
• inspect recent owner release/versioning practice;
• explicitly consider asking the user for the intended boundary/version rather
  than silently expanding scope;
• record the resulting decision when it establishes a reusable convention.

This should be a judgment rule, not a blanket confirmation requirement.

Concrete Migration-011 example

For the current Forge tooling integration, the user selected a patch release
from the existing v0.3.0 baseline. Forge API cleanup such as
fg_overlap_mm() retirement remains separate work and is not part of that
tooling-integration release.

Follow-up

Update shared versioning/release guidance once the policy is agreed. Keep the
exact-revision release rules unchanged; this issue concerns the decision that
precedes those mechanics.