ShellSyntaxTree's greedy verb walk (SPEC §6.1) folds a lowercase-leading
version token such as `v0.4.2` into the verb chain (`git tag v0.4.2`),
while a digit-leading `0.4.2` stops the walk and lands in Args (verb
stays `git tag`). Because ShellApprovalMatcher compared the full
`clause.Verb.Joined` for exact equality against persisted grants, the
same intent produced two different verbs: `git tag 0.4.2` matched a
standing `git tag` grant and ran instantly, while `git tag v0.4.2`
missed it and re-prompted. SPEC §6.1.1 warns that `Clause.Verb` is a
convenience hint, not a security contract, and that consumers must do
their own verb normalization.

Extend the issue netclaw-dev#1331 call-specific-value rule (bare integers) to also
cover version-shaped tokens, and apply it on both verb-chain paths so
they normalize identically:

- ExtractCandidatesViaBashParser (the gate) and ReconstructClauseText
  (the persisted/display pattern) run the verb tokens through
  TrimTrailingValueTokens, dropping trailing bare-integer and
  version-shaped tokens while always retaining the command word.
- IsVersionShapedToken requires a dot after the optional v/V+digit, so
  v0.4.2 / 1.0.0-beta.3 / 1.0+build collapse but v2, branch names, and
  hex SHAs are preserved.
- Verb equality matching is unchanged, so no other grant is broadened.

`git tag v0.4.2` and `git tag 0.4.2` now both normalize to `git tag`,
and a freshly-granted version generalizes across versions instead of
pinning to the one approved.

The fix targets the POSIX BashParser path; the Windows legacy
ShellTokenizer path takes a different route and is unchanged (tests are
POSIX-gated accordingly).

Replace the version-shape predicate (and the bare-integer special case
it composed with) with a single morphological rule: a token is a
call-specific value iff it is not a flag, not path-shaped, and contains
a digit. This deletes IsVersionShapedToken and IsBareIntegerToken in
favor of one IsCallSpecificValueToken.

The shape taxonomy approach accretes special cases (integers, dotted
versions, next SHAs, IPs, dates...) while still mis-drawing boundaries:
`git checkout v2` was preserved but `git checkout v2.0` stripped, and
alpha-leading SHAs (`git show aa211dc`) never normalized, so a
standing `git show` grant could not cover the dominant SHA use-case.
Under the digit rule versions, SHAs, range refs, IDs, and digit-bearing
ref names all normalize uniformly.

Boundaries that keep the rule safe:
- Trailing-only trim with a one-token floor: mid-chain tokens (`aws s3
  ls`) and command heads (`python3`) are never touched.
- Flags are exempt (`-3`, `--max-count=10` carry intent, not values).
- Path-shaped tokens are exempt so digit-bearing paths still reach
  directory scoping and display patterns.
- All-alpha operands (branch names, package names) are intentionally
  not classified: no shape rule distinguishes them from subcommands,
  and mis-stripping a subcommand silently widens a grant.