Why doesn’t a git tag show up on any branch?

My guess is the author probably had a branch that contained 91bfd82491f, tagged that commit, pushed the tag, and then later deleted the branch. You are also correct that the author may have a local branch that points to the same commit but pushed the tag only, not the branch.

Check which branch or branches contain v1.4.9 using

git branch -a --contains v1.4.9

Running that command gives no output, which confirms that it is not on a branch of its own. In contrast, look for v1.4.8:

$ git branch -a --contains v1.4.8
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/debian
  remotes/origin/master

One way to directly create a tagged commit outside any branch is to operate with a detached HEAD, that is where HEAD does not refer to a named branch. In the mosquitto clone, you can get there by running

git checkout v1.4.9

which gives you a chatty warning.

Note: checking out 'v1.4.9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 91bfd82... Merge branch 'fixes'

At this point, git will create more commits. For example:

$ touch look-ma-no-branch ; git add look-ma-no-branch

$ git commit -m 'Look, Ma! No branch!'
[detached HEAD 51a0ac2] Look, Ma! No branch!
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 look-ma-no-branch

This new commit 51a0ac2 does not exist on any branch, which we can confirm.

$ git branch -a --contains 51a0ac2
* (HEAD detached from v1.4.9)

For fun, let’s tag it too.

git tag -a -m 'Tag branchless commit' v1.4.9.1

Switching back to the master branch with git checkout master, we can use git lola (an alias for git log --graph --decorate --pretty=oneline --abbrev-commit --all) to see that the new tag looks similar to its progenitor.

$ git lola
* 51a0ac2 (tag: v1.4.9.1) Look, Ma! No branch!
*   91bfd82 (tag: v1.4.9) Merge branch 'fixes'
|\
| | * 1cd4092 (origin/fixes) [184] Don't attempt to install docs when WITH_DOCS=no.
| | * 63416e6 ;
| | * 5d96c3d [186] Fix TLS operation with websockets listeners and libwebsockts 2.x.
| |/
| * 2d0af73 Bump version number.
| | *   8ee1ad8 (origin/coverity-fixes) Merge branch 'fixes' into coverity-fixes
[...]

Confirm that it exists on no branch using

git branch -a --contains v1.4.9.1

Because you asked, no, this is not at all a common git workflow.

I did something similar by mistake: I was about to push a new release, I committed everything on my PC and added a tag.

Then I did git push --tags, thinking erroneously that it would push the master branch and the tag. Then I created a release on github. The release was pointing to the last changes, but the master branch was behind. I had to push again, and that aligned everything.

The notable thing is that all the files were actually pushed with the first command (I saw it from the output, you know: creating deltas, etc). In the second push the transferred bytes reported 0, so I guess only branch metadata were pushed.