Issue: Forum posts with wiki autolinks by new members get moderated status.

At the time of posting, the user who made the post only had 9 posts.

In AdminCP > Setup > Options > Spam Management, you have: Maximum messages to check for spam = 10
The user has 9 posts, so their message will be considered for spam.

If the post contains any of the words in "Spam phrases", the message will be treated as spam. In your "Spam phrases", you have the word "contact".
The user uses the word "contact" in the post, so the message is treated as SPAM.

When a message is treated a SPAM, you selected to "Manually approve".
The user's message was treated as SPAM, so the post goes into XenForo's approval queue.

This is a default feature of XenForo, and based on your chosen selections, and the content of the user's post, the feature is operating as expected. Marked as Not a Bug.

Ah yes, that is correct. But the issue in regards to Tickets lies a bit deeper I think. Tickets and ticket discussions should not get triggered by this. Yet they do. See ticket 3507 on my site. This ticket and discussion was also moderated.
https://xenforo.com/community/thread...7#post-1759296

I don't own the Tickets add-on so I can't see its code.

VaultWiki's autolinker does not modify the original content of any messages. If you were to edit a message that has been autolinked, you will see that there is no BB-Code added. The autolinking takes place entirely at render time. All spam checks that I have seen in XenForo always check against the original message content, before any rendering.

VaultWiki does not modify XenForo's Thread/CreatorService or add any extra moderation checks for other content-types. VaultWiki's content-types call external moderation checks, such as checking for spam, only when creating its own content via its internal entities. VaultWiki does not modify the moderation_state of any content other than content it has created.

Considering the number of addons you have and the number of moderation-related add-ons, it is likely something is modifying whatever service Tickets use to generate threads. For example, adding a call to $this->checkForSpam within Thread/CreatorService, which normally does not checkForSpam unless the calling function explicitly calls it. But possibly the Tickets addon actually calls checkForSpam... again I don't own it. I should also mention that Thread/CreatorService doesn't disabled its spam checker when setIsAutomated is used. The described behavior seems to be reserved to Conversations.

Since you are having trouble finding what causes this, my suggestion would be to find out what method Tickets uses to generate threads, then modify the source file of the Thread Entity to catch when one of its threads is set to moderation_state = 'moderated', then log to XenForo's log with a trace:
This will at least give you a call stack to work through and add more logging to.