Fix FORCE_NUKE_CERTS annotation, DRY up Patch Match Tables, extend .gitignore

[Hederstedt]

Summary

• Fix FORCE_NUKE_CERTS variable expansion in create_certs.yml — the warning annotation on line 86 used the literal string vars.FORCE_NUKE_CERTS instead of ${{ vars.FORCE_NUKE_CERTS }}, so the warning was never displayed when force-nuking certificates. Note: the actual nuke logic on line 94 was already correct and unaffected.

• Extract duplicated "Patch Match Tables" step into a reusable composite action (.github/actions/patch-match-tables/action.yml). The identical 8-line shell script was repeated in build_loop.yml, create_certs.yml, and add_identifiers.yml. Now each workflow references the shared action.

• Extend .gitignore with common development artifacts: buildlog/, artifacts/, .env files, fastlane temp files (new_certificate_needed.txt, report.xml), and .claude/ local config directory.

Test plan

• Verify 3. Create Certificates workflow runs successfully with FORCE_NUKE_CERTS=true and displays the warning annotation
• Verify 4. Build Loop workflow completes (Patch Match Tables step uses composite action)
• Verify 2. Add Identifiers workflow completes (Patch Match Tables step uses composite action)

🤖 Generated with Claude Code

[marionbarker]

Thank you for your input. I'm going to ask a few other developers in the open-source AID world if they want to modify the yaml files as you suggest.

We use the same files with minimal differences for Loop, Trio, LoopFollow, LoopCaregiver and to a certain extent xDrip4iOS. Often, the changes are tested in LoopFollow and then propagate from there.

Note - that we are already working through making a modification to the NUKE_CERTS part of build_x.yaml to make the variables case insensitive. (When typing variables on a phone, they automatically default to title case, i.e., True, whereas at the computer in a browser, if you type true you get true.)

I'm about to do a PR (that is almost independent of yours) based off of this LoopFollow PR 536.

In future: New PR are directed to the dev branch. If you direct one to main, we will move it to point to dev. So always start with your code aligned with dev. If there is work in progress to update dev, there will be a branch of the name update_dev_to_VERSION. In that case, it's a good idea to make sure you are not conflicting with that work in progress branch.

[marionbarker]

I checked with the other developers. We will not be adding changes from this PR to our ecosystem.

You specifically mentioned bugs. Can you elaborate on what you perceive as a bug as opposed to a "nicer" way to do a task. We already fixed the NUKE_CERTS problem and made it case insensitive.

We think all the required changes to github actions are found in v3.13.1 at this time.