fix(deps): pin Shiro to Java 8-compatible line (1.13.0)

[natechadwick-intsof]

Summary

Pins all org.apache.shiro:shiro-* artifacts to 1.13.0 — the last Java 1.8 compatible release. Shiro 2.0.0 dropped Java 8 support; 2.1.0 ships Java 11 bytecode (major version 55), which can cause UnsupportedClassVersionError on a true Java 8 runtime. 1.13.0 ships Java 8 bytecode (major version 52) and the org.apache.shiro.* API surface is unchanged for the ways this project uses it (web auth + JEE filter chain in shindig-uber).

This is the second half of the bytecode-mismatch bug originally tracked in #74. The BouncyCastle half was fixed by #77.

Why not just one direct version pin?

1.13.0 also pulls in shiro-cache and shiro-crypto-core transitively from shiro-core, and the spring/config/lang/crypto/event artifacts each have their own release line. Pinning shiro-core in dependencyManagement is not enough on its own — some modules resolved 2.1.0 for transitive artifacts (e.g. shiro-lang in shindig-uber) before this fix. The 9 dependencyManagement entries + the shiro.version property pin the whole shiro-* family in lockstep, matching the pattern from #77 and #79.

Touched files (2 files, +48 / −1)

File	Change
pom.xml (root)	+ <shiro.version>1.13.0</shiro.version> in <properties>; + 9 <dependencyManagement> entries: shiro-core, shiro-web, shiro-spring, shiro-lang, shiro-event, shiro-config-core, shiro-config-ogdl, shiro-crypto-hash, shiro-crypto-cipher
modules/shindig-uber/pom.xml	<version>2.1.0</version> → <version>${shiro.version}</version> on the only direct shiro-web declaration

No Java/import changes anywhere.

Verification

• ./mvn-env.sh clean install -DskipTests → BUILD SUCCESS in 3:56 (full reactor, 61 modules, Java 1.8.0_504)
• javap -v on every resolved shiro-*-1.13.0.jar → major version: 52 (Java 8 bytecode) for all 11 jars (the 9 directly managed plus shiro-cache and shiro-crypto-core that come in transitively)
• No UnsupportedClassVersionError in the build log
• The 2 pre-existing maven-shade-plugin <excludes> for shiro-web and shiro-core in modules/shindig-uber/pom.xml are left in place (they prevent the two jars from being included in the shaded uber-jar; that decision predates this PR and is independent of the bytecode fix)

Dependabot

org.apache.shiro* and org.apache.shiro:* were already in the .github/dependabot.yml full-ignore list (added before #75), so this won't get auto-bumped to 2.x in the future.

Out of scope

• Re-evaluating the maven-shade-plugin <excludes> for shiro-web/shiro-core (separate conversation — whether to shade them in is a packaging decision, not a bytecode fix)
• Whether to migrate to a maintained auth framework (separate epic; tracked in the parent [deps] Tier 1: drop-in Java 1.8 version bumps for 19 vulnerable GAVs (closes 153 CVEs) #72)
• The "tier1" group of dependency upgrades (separate PR chore(deps): tier1 dependency upgrades for Java 1.8 (issue #72, 13 of 19 GAVs) #79 covers 13 of 19 GAVs in the analysis report)

References

• Closes [deps] Pin Shiro to Java 8-compatible line (org.apache.shiro:shiro-* 2.1.0 -> 1.13.0) #78
• Original bug: [bug] bouncycastle 1.83 and shiro 2.1.0 are Java 11 bytecode in a pom that targets Java 1.8 #74 (closed as superseded by fix(deps): migrate BouncyCastle from bc*-jdk18on to bc*-jdk15to18 1.85 #77 for the BC half; this PR closes the Shiro half)
• BC fix: fix(deps): migrate BouncyCastle from bc*-jdk18on to bc*-jdk15to18 1.85 #77 (merged or open depending on timing)
• Shiro 2.0 release notes: https://shiro.apache.org/news.html — 2.0 is the first version that requires Java 11
• maven-shade-plugin exclude documentation: https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#excludes

Co-Authored by Mavis v1.0.0 using minimax-m3 with agent mavis.