fix(coc-nvim): resolve <CR> conflicts and enable proper insert-mode completion

[OlaleyeFisayo]

When integrating Coc.nvim into AstroNvim, I encountered issues with auto-completion — specifically the <CR> key not confirming completion items and the absence of expected smart formatting behavior.

After debugging, I discovered that nvim-autopairs was intercepting the <CR> mapping, which conflicted with Coc’s built-in completion and formatting logic. Since Coc already provides its own smart enter behavior and auto-pair handling, the most effective fix was to disable nvim-autopairs when using Coc.

This patch does the following:

• Disables the nvim-autopairs plugin to prevent <CR> mapping conflicts
• Adds default insert mode mappings for:
  • <CR> to confirm completion
  • <Tab> / <S-Tab> to navigate the popup menu
  • <C-Space> to manually trigger completion

This ensures a smoother and expected user experience when using Coc for autocompletion inside AstroNvim.

Tested with various filetypes and behaves as expected.

Let me know if you'd prefer this be added as a community plugin override instead.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).